Hacking Electronic Safes

Nice attack against electronic safes:

Plore used side-channel attacks to pull it off. These are ways of exploiting physical indicators from a cryptographic system to get around its protections. Here, all Plore had to do was monitor power consumption in the case of one safe, and the amount of time operations took in other, and voila, he was able to figure out the keycodes for locks that are designated by independent third-party testing company Underwriter's Laboratory as Type 1 High Security. These aren't the most robust locks on the market by any means, but they are known to be pretty secure. Safes with these locks are the kind of thing you might have in your house.

Posted on August 12, 2016 at 6:52 AM • 26 Comments


AnuraAugust 12, 2016 7:16 AM

I wonder how you can design these to prevent side channel attacks. My first thought would be salted hash, but the hash can still be recovered, and with a six digit numeric code it won't take long to brute force, especially since you would want a very long battery life for something like this which limits the use of key stretching algorithms. I don't know a lot about electronic circuitry, but it seems to me that if you can design it to store both the hash and the one's complement of the hash, and then compare them both in parallel, then the power consumption should not vary.

William WoodyAugust 12, 2016 7:43 AM

It sounds like these side channel attacks could be prevented by storing all six digits of the combination in an internal buffer regardless of the correctness of each digit, then running the computation to determine if the digits are correct or incorrect once the sixth digit is entered. That way, the processing time for each digit is the same as they are entered (because the digit is simply being stored regardless of correctness). If you also make sure your compare function does not have an early abort (meaning you always check all six digits and 'OR' a bit indicating correctness), you can keep the time used by the compare function identical--giving no hints as to which digit is wrong--and you minimize current variations during compare.

milkshakenAugust 12, 2016 7:54 AM

Looks like a major design blunder, for the lock to process the input piecemal instead of storing the input and processing it just once at the end. Also I don't understand why the processing is done in microseconds (rather than after maybe a one-second delay). You would expect from analogy of picking mechanical safe locks that these attack modes would be well understood

SoWhatDidYouExpectAugust 12, 2016 8:24 AM

Any power consumption should only be for charging the batteries in the safe. Otherwise, no power draw when the combination lock is being manipulated (during which time, power draw for charging is turned off).

CallMeLateForSupperAugust 12, 2016 8:32 AM

"Safes with these locks are the kind of thing you might have in your house."

Further, as the article points out, these locks are fitted on certain gun safes. The devious bastard in me fantasizes about flitting around the country, cracking said safes wherever found, piling lethal contents on the floor under a note: "Your safe isn't".

Better, create a maker project that automates the cracking.

JeffPAugust 12, 2016 8:38 AM

I'm unfamiliar with the implementation of these locks. "What you do here is place the resistor in series with the battery and the lock..." Is there easy access to the battery from the outside?

Dan3264August 12, 2016 9:00 AM

It looks like these locks have the battery accessible when the safe is locked. That does make sense(you don't get locked out permanently if the battery runs out), but it makes it rather easy to do side-channel attacks. I would want to have the battery on the inside of the device. Preferably it would be rechargeable, but charging it would disable the unlock feature while it is charging. @SoWhatDidYouExpect came to the same conclusions about charging. It makes sense if you think about it.

Clive RobinsonAugust 12, 2016 9:50 AM

The first hint of where the problem lies is in the first line of the article,

    “High security” consumer electronic safes

Which translates at best to "made to a price in a low profit market".

I have a whole bunch of electronic punch key safes that I've built computers in and I can tell you for free even the manufacture of the mechanics is fairly ropey, especially if it's main feature is an A60 fire rating.

The second hint is that UL rating like many other ratings is based on standardised tests. So in all probability "the design was to the test"...

But there is another issue that tends not to get talked about with electronic locks and that is "What do you do about a flat battery?"

Anyone who has a transistor radio or other battery powered device will know that battery life is dependent on several factors such as use and temprature.

Battery failure would in a secure design be either the first or second biggest "customer service issue" along with "forgetting the combination". Thus you have to ask what is the "fall back" in the design for battery failure?

I've seen various things like crappy mechanical key locks you might once have found on Ford pickups, having the battery accessible from outside the safe, and the likes of a RJ47 jack to plug a battery and "access keypad" into.

I could give you a long list of failings that the likes of UL have identified for these, but you'd not find "signals side channel attacks" on the list. Put simply there are otherwise easier attacks such as large ring magnets, over volting and the like. Whilst industry insiders have been aware of side channel attacks since the late 1980's doing it required a chunk of test equipment you'ld not be able to conceal suruptiously about your person. Thus it's been considered "to nerdy" for criminals to get involved with.

However that was not the attitude they took with non "consumer" locks. But even so I know for certain that even some professional quite high security locks fail to timing attacks you can pick up with a nail with fifty or so turns of wire around it put up against the keypad. The signal put through the likes of an OpAmp amplifier and viewed on an oscilloscope you can clearly identify changes in the ket scan rate as long as a key is pressed. The scan rate is often interlaced with the other "lock software" rather than from the interupts, therefore changes in processing times become visable.

As others have noted the checking of the key code should be done bot on a key by key basis but... There are legacy reasons why it's done that way, two reasons you will see are firstly the key code length is user asigned from four to nine digits. Secondly the old thing about alowing any key entry and opening if the last n-digits match the key code. Such specifications are usually "optimised" by the design engineers to use the lowest spec --thus cost-- parts and to minimise battery consumption...

As they say at the end of all presentations "Any questions" ;-)

Clive RobinsonAugust 12, 2016 10:01 AM

Oh I forgot to mention, rechargable batteries are considered a "no no" in electronic locks.

Firstly because their charge hold time is appaling, measrued in weeks or a couple of months not the years you get with certain dry cell types. Secondly because of the low current drawn some rechargable batteries fail short after just a few charge cycles. Thirdly since a particular battery type burst into flames inside a hotel door lock UL reject certain battery types for safety reasons.

This problem is one that is realy vexing scientists who are trying to meet the "100 year" requirment for locks on nuclear waste depositories. They have found that not just batteries fail, high value capacitors do as well, so even a weight on a mechanical mechanism like a clock release driving a generator to charge capacitors does not work...

Steve PolleiAugust 12, 2016 11:40 AM

{{Plore did have to find a way around the safe’s “penalty lockout feature” that shuts everything down for 10 minutes after five incorrect input attempts, but ultimately he was able to get the whole attack down to 15 minutes}}

I wish they also mentioned how he did that. Was it as simple as disconnecting the battery?

TatütataAugust 12, 2016 12:01 PM

Plore observed that as the system checked a user code input against its stored values there was a 28 microsecond delay in current consumption rise when a digit was correct. The more correct digits, the more delayed the rise was.

It sounds like there is a short-cut logical function evaluation at play here : break out of the verification routine as soon at the first detected false digit. A delay of 28us sounds like the performance of some really sloooooow toaster chip and/or compiled code.

Could it be that the safe's software is written in a high level computer language using some form of optimising compiler? Even for a 20-year old design I would have trouble finding forgiveness.

One might have better control over the timing and profile by implementing the critical part in assembler.

A long time ago I wrote asynchronous serial I/O routines on the Z80 and 6502 processors. The clock cycle counts were perfectly predictable, and by being very careful I was able to poll for other events within the loop. I'm rather convinced that with that level of care and a good oscilloscope you might be able to make the task more difficult for safe-knackers.

One might intertwine an obfuscating loop generating a pseudo-random electrical load with the verification routine.

BarrettAugust 12, 2016 12:10 PM

I once had to 'hack' a safe with an electronic lock.

In my case the battery died. The safe had a backup physical key hole which I did not have the key for.

With a flathead screwdriver pressed against the key hole and few firm hammer strikes the key hardware was knocked through the front face-plate. Then with my finger I was able to unlock the safe.

The whole 'hack' took about 15 seconds.

TatütataAugust 12, 2016 12:43 PM

{{Plore did have to find a way around the safe’s “penalty lockout feature” that shuts everything down for 10 minutes after five incorrect input attempts, but ultimately he was able to get the whole attack down to 15 minutes}}

I wish they also mentioned how he did that. Was it as simple as disconnecting the battery?

My guess: after four incorrect attempts the battery line is momentarily shorted out (the current is limited by a resistor anyway) in order to have the program reset the counter after power up.

Def ConnorAugust 12, 2016 2:19 PM

Re: Beating the 5 failure lockout
@Tatütata / @Steve Pollei

I was at the talk. It was a really clever trick to get past the lockout.

Basically, he found out that due to the storage medium being a type of flash, that when the controller writes it must first zero out the storage location then write the new value. The code would increment the failed attempt counter *after* the check failed, instead of following best practices of increasing the counter *before* doing the check.

He was able to find a timing window in which he could cut power to the board at just the right time after it wrote the 0s but before it could write the incremented counter value.

Pretty clever!

TatütataAugust 12, 2016 2:49 PM

Aha, OK, thanks. I didn't consider the possibility of using flash, I thought this thing was operating entirely out of RAM.

If it had actually been the case, I would have implemented a ten-minute lockout right a power-up for the first wrong entry.

Bobbie MathewsAugust 13, 2016 6:18 AM

Nifty trick, and worth fixing if you're the manufacturer. But as a rule of thumb, I'd say if a stranger has broken into your house and is leisurely connecting a resistor to your safe, things aren't looking rosy.

guestAugust 13, 2016 10:56 AM

@Clive Robinson
Can you share some references to learn more about the 100 year locks? Sounds like a fascinating engineering problem.

Jonathan WilsonAugust 14, 2016 6:49 PM

The problem here isn't insecure safes or even insecure electronic safes. Its about insecure cheap safes.

If I wanted a good safe I would go to a proper locksmith/safe shop and buy a safe with a high quality dial combination lock. No electricity needed. No batteries to run out of juice. And if its built properly, it will take too long to manipulate open for a thief to bother with it. (and a good one will have glass re-lockers and other anti-destructive-entry protections as well to prevent drilling and such)

GregAugust 14, 2016 7:19 PM

I once "hacked" the safe in my hotel room after forgetting my key. On the keypad with digits and A and B keys. Instructions were to set the your key using the A button. However, the same pattern with the B key set an alternative key. A quick search with Google revealed the default B key, which was unchanged...

Jonathan WilsonAugust 15, 2016 6:05 AM

A lock like the Sargent and Greenleaf 2740B shows that it IS possible to produce an electronic safe lock that isn't vulnerable to any of the attacks described in this article. So its only manufacturers of cheap crappy safes (with cheap crappy locks) that need to worry about the attack described in this article, not high-end manufacturers like Sargent & Greenleaf...

Clive RobinsonAugust 15, 2016 7:18 AM

@ Jonathan Wilson,

A lock like ... shows that it IS possible to produce an electronic safe lock that isn't vulnerable to any of the attacks described in this article.

Whilst that limited qualification might be true, I've seen way to many high security way to high cost locks fail. And that is both mechanical and electronic locks.

Nearly all the failures were not due to high tech attacks using precision tools and electronic test kit. Many were simple attacks involving things like ring magnets, soft plastic like Bic Biro caps, tin foil from chewing gum wrappers, engineer's blue, oh and Newton's laws. Basicaly attacks the locks designers had failed to consider / mitigate.

I've bypassed mechanical locks with a camera and needle files, with no need to "impression" a key. Somewhere on this blog you will find a comment from Bruce of acknowledgment for new knowledge when I first posted about using a camera.

The simple fact is the mechanical parts of locks can not be made beyond a certain tolerance and the resulting "slop" will always alow someone to "feel" a way around. Likewise electronics is far from perfect and has power issues that allow a whole bunch of attacks I won't go into here. But worst of all has to be the software component of CPU controled locks. The people writing that software have little or know knowledge of EmSec attacks, or other aspects of security and this we get miserable fails.

But even when code cutters do have security training and knowledge their systems fail. You only have to look at the Banking Industries inability to come up with secure electronic payment systems via token or app to see that those who do such "security design" are not up to the minimum security you would expect.

It is said that "Everybody has a weakness that can be exploited" well the same applies to many of "mankinds creations". I'll leave it to others to work out why this might be considerably worse than it could or should be.

SJAugust 15, 2016 8:51 AM

I would think that Underwriter's Laboratory does not have any expertise in the realm of cryptography.

My impression was that consumer-grade safes are typically tested by UL in several ways:

1. Fire resistance

2. Number of minutes that it can resist an attacker armed with only a steel pry-bar

3. Number of minutes that it can resist an attacker armed with a hand-held drill

Safe-cracking of a tumbler is also well-known to the UL, but safe-cracking of electronics by side-channel attack isn't well-known.

On the practical side: I own such a safe. My primary thought at time of purchase was to keep certain items (collectible rifles and hunting shotguns) safe from a quick snatch-and-grab. It's not good against a persistent attacker. Especially one who brings along the necessary equipment to remove the safe from my property, and attack it at leisure elsewhere.

This second weakness is shared by any safe that isn't integrated into the building structure.

The electronic lock on my safe has an easily-accessible 9V battery on the outside, which annoys me. But the cost/benefit factor meant that this safe was accessible in-budget when I wanted to purchase it, rather than me waiting until a better safe was accessible in-budget.

I had the annoying problem of bringing the safe home from the retail store, trying the default code, getting the "valid code" beep, but being unable to open the safe.

After a couple of minutes on the phone with the store-representative, they asked me if I could change the battery.
I immediately discovered that the lock mechanism could be too heavy for the battery to release, even if the battery was still capable of running the electronics that could validate the code.

GruikAugust 15, 2016 6:33 PM

Can you share some references to learn more about the 100 year locks? Sounds like a fascinating engineering problem.

Easy: make the lock from the stuff it's supposed to protect. After all, nuclear waste lasts forever.

For document sources, I suggest Hollywood. You know, where Indiana Jone leans on the wall in the millennium old temple, and inadvertently unlocks the entrance to the secret passage.

Anon10August 15, 2016 7:27 PM

@Jonathan Wilson

2740b aren't available to the public. They're only for sale to the government and approved government contractors. The hack was done against a Sargent and Greenleaf lock, although the 6120 was an older model developed in the 1990s. Your broader point remains that more secure locks are out there, but they're probably wasted money unless you're getting a safe that's at least trtl-30x6 rated.

ThunderbirdAugust 16, 2016 4:49 PM

I didn't consider the possibility of using flash, I thought this thing was operating entirely out of RAM.

If it had actually been the case, I would have implemented a ten-minute lockout right a power-up for the first wrong entry.

The problem with that idea is that every time you change the battery you have to wait ten minutes before you can unlock your safe. That seems likely to piss off the legitimate user.

I suspect the threat model didn't include anyone monitoring the electronics, so it just never occurred to the designers. Like Clive says, consumer locks are not usually designed to keep out James Bond--just Jacques Clouseau.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.