Hey guys. So, uh, who here likes locks? Yeah? Alright, who here likes safe locks? Yeah?
Who here likes cracking safe locks? Yeah? Okay. So, you know, I have a safe. It's kind
of similar to one of these. Um, it's a fairly decent sized gun safe. Has an electronic lock
on it. And one day I was thinking, gosh, I wonder how secure is that? Is it, you know,
how better than the mechanical counterparts? So I started investigating. Found a few
things. Uh, first of all, for some context, what we're talking about here. We're talking
about high security electronic safe locks, type one. This is a UL listing. This is, these
are decent locks that you're gonna find on reasonably sized gun safes typically, often
times in residences. What we're not talking about, we're not talking about the cheap crappy
locks that you're gonna find on hotel safes or fire safes or things like that. Those cheap
crappy locks, you can often defeat those with a magnet or by spiking them with some wires
or anything like that. The, uh, the, uh, the, uh, the, uh, the, uh, the, uh, the, uh, the
high security locks are designed to be impervious to that. On the other hand, we're also not
talking about GSA locks. It's a bit of a different, uh, different topic. Um, so, we look at two
locks. The first of the locks is made by a company called Sargent and Greenleaf. Sargent
and Greenleaf is a large, reputable manufacturer of locks, both mechanical and electronic.
They're about 150 years old. This particular lock, the first lock we're looking at, is the
6120. It's a bit of an older design, designed in the mid-90s. It's a little bit older than
the other locks. It's a UL-listed lock. Um, still made and sold, at least as of late
last year. So, the way this lock is designed, all of the logic exists inside of the safe.
The only things outside of the safe are a keypad, which consists of a resistor ladder
keypad and a user-replaceable 9-volt battery. Inside the lock is where the microcontroller,
the MTU, and the EEPROM exists, as well as a motor to drive an acne screw that will either
extend or retract the bolt. So, what I, when I started looking at this, I thought I'd look
at something called power analysis. This is a side-channel attack. What you do here is
place a resistor in series with the battery and the lock. And by monitoring the voltage
across that resistor, we can learn how much current the lock is drawing at any particular
time. And from that, we can learn something about the state of the lock. What this
allows us to do in particular, in this lock, is monitor the data line between the MCU and the
EEPROM. So, you can kind of imagine that this lock has something like a spy bus. So, we have a
single data line going between the microcontroller and the EEPROM. And this data line is pulled up,
perhaps, by a resistor. Well, when you have a higher voltage on that line, the voltage across
that pull-up resistor is going to be lower. So, your current drain is going to be low. And when
you have a zero, a low voltage on that line, the current drain is going to be lower. And when you
have a higher voltage on that line, there'll be a drop across that pull-up resistor. So, the
current will be, the current drain will be slightly increased by the lock. So, we can
monitor the amount of current being consumed by the lock externally. We can learn, then, what's
on the data bus. Uh, this is, in fact, a screenshot. I opened one of these locks up and
probed both the actual data line, as well as monitoring the amount of current being consumed
by the lock in real time. The yellow trace is the actual data line, and the blue trace
is the current consumption. As you can see, each of these spikes represent one bit being
clocked out of the EPROM. And when the data line is high, it turns out that the current
consumption is slightly lower, about 60 microamps lower than if there's a zero at that state,
in, uh, that position in the EPROM where it'd be read out. All right. So, let's take a look at
what this looks like in, uh, in a video here, a video demo. So, let's take a look at what this
looks like. All right. So, what we're gonna do is we're gonna enter any old code on the keypad.
Doesn't matter what it is. It's definitely gonna be the incorrect code. Doesn't matter what it is.
Now, in the background, we have a scope monitoring the current being consumed by the lock. And
each of these little bursts is a word being read out of EPROM. Now, the key, again, the lock
stores the code in EPROM. So, what we're going to do is zoom in, look at the first couple of
these bursts. Each of these little spikes is one bit.
Being read out of the EPROM. Again, this is just the current consumption. This is all done
externally from the safe, external to the lock. We go in, we zoom in, and we can see that the
first two digits for the lock are eight and zero. We go over to the next word being read out of
EPROM. And the next two digits in the key, in the actual key code are one and nine. And the
final digits, then, you can see, would be four and five. Again, the lower current is a one, and the
higher current is a zero. So, by starting with any old key code, the wrong key code, we learned
what the right key code was by watching the current consumption of the lock. So, let's go back
over to the lock, try that, eight, zero, one, nine, four, five, that key code. And we see that
the lock bolt retracts down at the bottom of the screen. So, yeah.
So, then, I thought, well, you know, that was, uh, sort of a, you know, a little bit of a
mistake. So, I got a somewhat older lock. Again, it's still sold, but it was a kind of older design.
I wonder, have they improved? So, I got a newer lock from Sargent and Greenleaf. Again, this is a
Titan pivot bolt. This is part of the Titan family. Um, other locks in the family are the
Titan D-drive. Basically, the same internals. Same exterior components. It's a plug and play
replacement for one of these older locks. Still a passive keypad on the outside. Still access to the
battery. Inside, it's a little bit different. Instead of having a, uh, separate microcontroller
or an EPROM, we have a new lock. So, I got a new lock from Sargent and Greenleaf. Again, this is a
single chip doing everything. We have a STM8, which includes a few K of onboard EPROM. So, the
old attack from 6120, the older Sargent and Greenleaf lock, uh, doesn't work here. Um, however,
I was poking around and eventually came to realize that when the Titan lock starts a
comparison of the code that was entered by the user to the code that's stored in EPROM, so to
the true code, it does it one digit at a time.
And, if there's a mismatch, it will abort, break out of that comparison loop, then go off and buzz
and do some other stuff. So, you might be thinking, gosh, that sounds like a timing attack, and
indeed it is. Um, in fact, there is a 28 microsecond difference per digit, uh, depending on
whether or not that digit is the correct digit. So, what this lets us do is far more efficiently
search the key space for the correct key code.
Now, to do this, you need some markers. You need to know when to start the clock and when to end the clock.
Turns out that, once again, we can bring power analysis back into the fold, like from the older lock.
We have a great marker for the start of a timer. This corresponds to when the user presses the pound key
to indicate that they have entered the code. 29.6 milliseconds or so later, there is a second rise in the
amount of current being consumed by the lock. And it's this difference between that first current marker and that
second current marker that we can use to infer whether or not we have a match for a particular digit or a
mismatch for a digit. That time will vary by 28 microseconds.
Alright, so how this would work. What you would do if you're using this to your advantage is you would start with
some arbitrary key code. Then you would cycle through the various values for the first digit, zero through nine.
And you would keep the other value, other digit values fixed.
So you'd go zero, et cetera, et cetera, et cetera. Then one, et cetera, et cetera, et cetera.
And then you would look at the time required to go between those two current markers and whichever digit,
whichever value for that digit had the longest time delay, that's the correct value for that digit.
Alright. So in this example here, we found that the first digit is nine. Alright, once we found the first
digit, we repeat the cycle with the second digit. We use the digit we just found.
And then cycle the second digit through zero, then one, then two, then three, then four, et cetera.
Holding the remaining digits fixed. And repeat this again off until the fifth digit.
So this allows us to much more efficiently search for, through the possibilities for this key code.
The sixth digit's a special case. We'll get to that in a little bit. But the timing attack works great
for the first five digits. Now, you might be wondering, well how does that actually look on the
real world? And this is how it looks. This is looking at a zoomed in version of the second current rise.
This is the second marker that we're using. And at the top of the, of the scope shot, we can see
overlaid different runs where there was, there were zero digits correct and then one digit correct in
sequence. And then where there were two digits, the first two digits were accurate and the remaining
were wrong. And then where there were three wrong, accurate and then wrong, four and five.
So as we got more digits correct in series, we extended out our, our time delay.
It's still a problem though because this lock includes a feature called a penalty lockout.
If you enter the wrong key code five times in a row, it will lock you out and prevent any additional
attempts for ten minutes. Now, you can't get around this by pulling the battery. You can't get around it by,
you know, accelerating the clock or something like that. You really have to wait.
Ten minutes once this has started. So I thought, well, I wonder if you could prevent it from starting in the
first place. I wonder if perhaps we could do something like cut power to the lock prior to it writing this
incorrect attempt count to EEPROM. And so I did some investigation, got another STM8, just like the one
that is in the lock, and fiddled with killing power to it at various times. What I found was actually
even better. So it turns out that if you,
start a write to an address in EEPROM on the STM8, and then you kill power to that microcontroller between
500 microseconds and 2.5 milliseconds after the start of that write, what you'll be left with is not the
original value, not the, um, new value, you'll be left with zero. And so the reason this works is
because in EEPROM, in Flash, before you can write a new value to a destination that already has a value,
you need to erase that destination byte. And in the STM8, a little unusually, the erase value is zero.
Often times in other EEPROMs and Flashes it'll be FF. But in the STM8 it's zero. And moreover, the lock
firmware appears to treat zero as a valid value. So, uh, all we need to do is kill power to the MCU
between 500 microseconds and 2.5 milliseconds after the write to that incorrect attempt count. And so
that's what the incorrect attempt counter starts. Alright, so, turns out, even better, we know
exactly when to do that. That second current rise that we used for the timing attack ends up being
actually the start of the write for the incorrect attempt count. So if we key on that, we can
accomplish our goal. We can, um, first of all, we're able to get the voltage low enough quickly
enough. If we start at a somewhat lower distance, we can get the voltage at a slightly lower
voltage is still valid, we can actually get below the brown out
voltage for the microcontroller in about 600 microseconds. So we
know we can get there once we start. The question is then when
to start that power, cutting that power to the lock. And since
we have that current rise from the start of the EPROM right,
key off of that, takes us about 500 millis, 500 microseconds to
recognize what's happening and to then begin, cut power to the
lock with a FET, a very fast switch. In total, 1.1
milliseconds from when the write starts to when the lock is below
the brown out voltage. Once it's below the brown out voltage, any
pending part of the EPROM erase cycle or write cycle will be
aborted. 1.1 milliseconds, of course, is well within our
window between 500 microseconds and 2.5 milliseconds. So you put
this all together and what this lets us do is
have an infinite number of attempts to guess the key code.
You go through, say, four attempts or five attempts and
then you reset the key, the invalid attempt count back to
zero. So this allows us to, um, to both get the sixth digit and
also more efficiently search for the first, for the first five
digits. The reason it helps with the sixth digit is because we
just want to brute force that. We want
to go through and try, knowing the first five digits, all the
possibilities for the sixth digit. So we'll just go through,
try each of them, and, um, every periodically we'll reset the
invalid attempt count and just keep going through all ten
possibilities for that sixth digit. Alright, so attacking this
lock I couldn't, I couldn't just do it with a resistor. So the
first lock, you know, you had a scope and a resistor, you know,
that's like, like, uh, first week of freshman double, you
know, electrical engineering class sort of stuff.
Um, this is a little more complicated in that I need to
build a custom board to support this. This has a micro RAM meter
on it. This has some support circuitry to, to allow us to
emulate key presses. This is essentially just allowing us to,
um, present, present different voltages to the lock, emulating
a key, certain key values. Um, and also the power supply and
control, uh, mechanism to allow us to cut power at very, uh,
very precise times. So we then look at the algorithm used in
the lock. It's very similar to the, um, what we described
earlier. We first use the timing attack to find the first five
digits. We'll go through and have, try all possibilities for
the, all ten possibilities for that first digit value. Whichever
one has the longest time delay, that's the first digit, the
actual first digit value. We use that first digit value and then
try cycling through the second digit values. Whichever of those
has the longest delay, that's the second digit value and so on.
And then we, like I mentioned before, we'll brute force that
sixth digit by trying all ten possibilities there. And then we
go through and have, try all possibilities there. All the
while resetting the, uh, lock out attempt count periodically.
So, let's take a look at that. So here we have the, uh, the
support board. It's blue and we have the STM32 board. This is
where the attack firmware is running on it. The STM32 is a
little ARM Cortex M4 with a pretty good, uh, ADC on it. The
scope in the background is just monitoring the current
consumption. It's just there for visual effect. Um, as it cycles
through the various possibilities, it's able to
measure each of these possibilities for the keycode.
Uh, it has to do something over sampling. So in a real world
environment there is so noise. So we want to try these
potential, uh, co- combinations multiple times. And so for that
reason, this video is actually speed up by a factor of ten to
fit it in the presentation. Um, even so, the, the full attack in
a fairly robust manner, takes about 15 minutes. Which is a huge
improvement from the potential 3.8 years that a naive brute
force attack would take on the lock.
And as the attack firmware cycles through
and finds the true values for each of these digits
in the key code, eventually we'll reach the sixth digit.
We'll be monitoring the buzzer line
to figure out when it has the correct code,
because the lock will buzz in a different way
depending on whether or not you have entered
the correct or incorrect code.
And once it detects a correct buzz,
it says, oh, we found the correct code.
And we'll stick with that.
And we'll then flash a little green LED
and allow that located key code to be replayed.
There's a button on the board,
and when you hit the button,
it would then replay that identified key code.
So that's what's gonna happen right now.
There it is, it found the final digit.
The lock is locked.
Let's see, I'm trying to pull it with my thumb.
And we're gonna hit the button.
It's replaying the key code, and the lock is opened.
So, there we go.
And then, after five seconds,
the lock will relock itself automatically.
All right, so, you know, having said all that,
burglars are not gonna bother with this.
Like, they're just gonna use a crowbar
or the hydraulic jack from your garage,
or something like that.
Maybe if they're really fancy, they'll use a torch,
but that's really only, like, movie stuff.
I think the more interesting thing about burglars
is that they're not gonna be able to use a torch,
So, you know, the other thing here is,
but perhaps, applicability to other systems.
And we see other systems that have these sorts
of lockout mechanisms, you know,
maybe phones or other locks.
And I wonder if maybe there might be something similar
that could be applied there.
And, you know, the shame is that each of these issues,
it's actually fairly easy to fix in software.
Even the original lock, which seemed like a hardware issue,
that could be addressed in software
if they just didn't store the data,
the key code, in clear text.
I mean, don't store your data in the clear.
I think, you know, you'd think that would be common knowledge,
but I guess not.
So then the timing attack,
what you could do to mitigate that,
would be to do your comparison in constant time.
Don't abort your search or your comparison loop early
if there's a mismatch.
Go all through the way,
and you'll get to the end.
The EPROM manipulation, a little more complicated.
The way you'd get around that,
or the way you'd defend against this attack,
is to assume failure first.
So assume that the user will enter the wrong code
and increment that invalid attempt count first.
And then if they ended up actually entering the right code,
then clear that out.
Enter a zero for that.
That would still leave you with the possibility of erasing it,
forcing an erasure of that destination.
But what you could do with error is treat the erase value
for wherever you're storing this data,
Flash or EPROM or wherever,
treat that value as an invalid value.
So instead of treating zero as zero,
you know, why not treat that as invalid
and maybe relock it harder.
So the, I should also disclose that
I've been trying to get Sgt. Greenlee's attention
about this since February,
and they haven't been providing any useful response.
So that's a bit disappointing,
but I'm hopeful that they'll go forward
and make some improvements in the future.
There are better locks out there, I should mention.
There's a federal standard for GSA-approved locks.
It's FL 2740B.
And this standard is designed to defend
against this sort of attack.
So if you really want a good electromechanical lock,
I would recommend some sort of
GSA-approved lock.
They're kind of expensive, though.
So feel free to email me if you have any questions.
So thanks, guys.