00:00:01.201-->00:00:07.674
Hey guys so, uh, who here likes
locks? [murmured assent] Yeah?
All right. Who here likes safe

00:00:07.674-->00:00:12.980
locks? [murmured assent] Yeah?
Who here likes cracking safe
locks? [louder assent] Yeah?

00:00:12.980-->00:00:18.118
Okay. So, you know, I have a
safe. It's kinda similar to one
of these. Umm it's a fairly

00:00:18.118-->00:00:22.723
useful size gun safe. It has an
electronic lock on it. And one
day I was thinking: "Gosh I

00:00:22.723-->00:00:28.161
wonder how secure is that? Is it
how better than the mechanical
counterparts?" So I started

00:00:28.161-->00:00:33.300
investigating. Found a few
things. First of all, for some
context, what we are talking

00:00:33.300-->00:00:37.871
about here. We are talking about
high security electronic safe
locks type one. This is a

00:00:37.871-->00:00:42.242
[indistinct] listing. This is,
these are decent locks you're
going to find on reasonably

00:00:42.242-->00:00:47.547
sized gun safes typically. Often
times in residences. What we are
not talking about, we are not

00:00:47.547-->00:00:52.386
talking about the cheap, crappy
locks that you are going to find
on hotel safes or fire safes or

00:00:52.386-->00:00:56.089
things like that. Those cheap
crappy locks you can often
defeat those with a magnet or by

00:00:56.089-->00:01:01.929
spiking them with some wires or
anything like that. The uh,
these high security locks are

00:01:01.929-->00:01:05.198
designed to be impervious to
that. On the other hand we are
also not talking about GSA

00:01:05.198-->00:01:11.305
locks. That's a bit of a
different uh, a different topic.
Um. So, we're going to look at

00:01:11.305-->00:01:16.610
two locks. The first of the
locks is made by a company
called Sargent and Greenleaf.

00:01:16.610-->00:01:21.214
Sargent and Greenleaf is a
large, reputable manufacturer of
locks, both mechanical and

00:01:21.214-->00:01:25.452
electronic, they are about a 150
years old. This particular lock,
the first lock we are looking

00:01:25.452-->00:01:30.057
at, is the 6120. It's a bit of
an older design, designed in the
mid 90's. It's a [indistinct]

00:01:30.057-->00:01:35.062
listed lock. Um, still made and
sold, at least as of last year.
So the way that this lock is

00:01:37.097-->00:01:43.270
designed all of the logic exists
inside of the safe. The only
things outside of the safe are a

00:01:43.270-->00:01:49.343
keypad, which consists of a
resistor ladder keypad, and a
user replaceable nine volt

00:01:49.343-->00:01:55.649
battery. Inside the lock is
where the microcontroller (the
MCU) and the EEPROM exists as

00:01:55.649-->00:02:00.587
well as a motor to drive an acme
screw that will either extend or
retract the bolt. So, what I, I

00:02:05.492-->00:02:09.062
want to start looking at this. I
thought I'd look at something
called power analysis. This is a

00:02:09.062-->00:02:14.901
side channel attack. What you do
here is place a resistor in
series with the battery and the

00:02:14.901-->00:02:19.906
lock and by monitoring the
voltage across that resistor we
can learn how much current the

00:02:23.210-->00:02:26.380
lock is drawing at any
particular time. And from that
we can learn something about the

00:02:26.380-->00:02:32.686
state of the lock. What this
allows us to in particular in
this lock is monitor the data

00:02:32.686-->00:02:37.691
line between the MCU and EEPROM.
So you can kinda imagine that
this lock had something like a

00:02:40.127-->00:02:45.098
spy bus so we can have a single
data line going between the
microcontroller and EEPROM and

00:02:45.098-->00:02:50.871
this data line is pulled up by,
perhaps, a resistor. Well, when
you have a higher voltage on

00:02:50.871-->00:02:55.642
that line the voltage across
that pull-up resistor is going
to be lower you your current

00:02:55.642-->00:03:00.347
drain is going to be low and
when you have a zero, a low
voltage, on that line there'll

00:03:00.347-->00:03:04.918
be a drop across that pull-up
resistor so the current will be
the current drain will be

00:03:04.918-->00:03:10.624
slightly increased by the lock.
So we can monitor the amount of
current being consumed by the

00:03:10.624-->00:03:17.064
lock externally. We can learn
then, what's on the databus. Ah,
this is in fact a screenshot I

00:03:17.064-->00:03:22.869
opened one of these locks up and
probed both the actual data line
as well as the amount of current

00:03:22.869-->00:03:28.975
being consumed by the lock in
real time. The yellow trace is
the actual data line, and the

00:03:28.975-->00:03:34.681
blue trace is the current
consumption. As you can see each
of these spikes represent one

00:03:34.681-->00:03:40.520
bit being clocked out of the
EEPROM and when the dataline is
high, turns out that the current

00:03:40.520-->00:03:46.460
consumption is slightly lower,
about 60 microamps lower than if
it was a zero at that state. At

00:03:46.460-->00:03:53.400
that position in the EEPROM,
were it being read out. Alright.
So, let's take a look at what

00:03:53.400-->00:03:59.973
this looks like in ah, in the
video here. Video demo. Alright
so what we're going to do is

00:03:59.973-->00:04:04.811
we're going to enter any old
code on the keypad. It doesn't
matter what it is, it's

00:04:04.811-->00:04:08.515
definitely going to be the
incorrect code. IT doesn't
matter what it is. Now, in the

00:04:08.515-->00:04:14.221
background we have a scope
monitoring the current being
consumed by the lock and each of

00:04:14.221-->00:04:19.392
these little bursts is a word
being read out of EEPROM. Now
the key. Again the lock stores

00:04:19.392-->00:04:26.333
the code in the EEPROM. So What
we're going to do is ah, zoom
in, look at the first couple of

00:04:26.333-->00:04:30.971
these bursts, each of these
little spikes is one bit being
read out of the EEPROM. Again

00:04:30.971-->00:04:34.274
this is just the current
consumption, this is all done
externally from the safe

00:04:34.274-->00:04:41.014
external to the lock. We go and
we zoom in and we see that the
first two digits of the lock are

00:04:41.014-->00:04:46.019
8 and 0. We go over to the next
word being read out of EEPROM
and the next two digits from the

00:04:49.556-->00:04:54.561
key, of the actual key code are
1 and 9 and the final digits
then you'll see will be 4 and 5.

00:04:57.564-->00:05:04.171
again the lower current is a one
the higher is a zero. So by
starting with any old keycode,

00:05:04.171-->00:05:07.874
the wrong key code we learned
what the right key code was by
watching the current consumption

00:05:07.874-->00:05:12.879
of the lock. So let's go over
back over to the lock and try
that: 801945, that key code, and

00:05:15.215-->00:05:21.321
we see that the lock bolt
retracts, down at the bottom of
the screen. [applause] So...

00:05:21.321-->00:05:26.326
[applause] Yeah... [applause] So
then, I thought: well, you know,
that was somewhat of an older

00:05:29.729-->00:05:34.100
lock again still sold, but it
was kinda an older design. I
wonder have they improved? So I

00:05:34.100-->00:05:39.039
got a newer lock from Sargent
and Greenleaf again. This is a
Titan PivotBolt. This is part of

00:05:39.039-->00:05:43.376
the Titan family, umm other
locks in this family are the
Titan D-Drive. Basically the

00:05:43.376-->00:05:49.649
same internals, same exterior
components. It is a plug and
play replacement for one of

00:05:49.649-->00:05:54.487
these older locks. Still a
passive keypad on the outside,
still access to the battery.

00:05:54.487-->00:05:58.625
Inside is a little bit
different. Instead of having a
uh, separate microcontroller and

00:05:58.625-->00:06:04.965
EEPROM, we have a single chip
doing everything. We have an
STM8 which includes a few K of

00:06:04.965-->00:06:10.971
onboard EEPROM. So the older
attack for the 6120, the older
Sargent and Greenleaf lock, that

00:06:10.971-->00:06:17.944
doesn't work here. Umm. However,
I was poking around and
eventually came to realise that

00:06:17.944-->00:06:24.384
when the Titan lock starts a
comparison of the code that was
entered by the user to the code

00:06:24.384-->00:06:30.457
that is stored in EEPROM, so to
the true code, it does it one
digit at a time and, if there's

00:06:30.457-->00:06:36.329
a mismatch it will abort, break
out of that comparison loop and
then go off and buzz, do some

00:06:36.329-->00:06:40.634
other stuff. So you might be
thinking, gosh that sounds like
a timing attack and indeed it

00:06:40.634-->00:06:45.639
is. Umm, in fact, there is a 28
microsecond difference per
digit. Depending on whether or

00:06:49.009-->00:06:54.981
not that digit is the correct
digit. So what this lets us to
is far more efficiently search

00:06:54.981-->00:07:01.254
the key space for the correct
key code. Now to do this you
need some markers. You need to

00:07:01.254-->00:07:05.558
know when to start the clock and
when to end the clock. Turns out
that once again we can bring

00:07:05.558-->00:07:11.364
power analysis into the fold
from the older lock. We have a
great marker for the start of a

00:07:11.364-->00:07:16.870
timer this corresponds to when
the user presses the pound key
to indicate they have entered

00:07:16.870-->00:07:23.143
the code. 29 point 6
milliseconds, or so, later there
is a second rise in the amount

00:07:23.143-->00:07:28.748
of power being consumed by the
lock and it is this difference
between the first current marker

00:07:28.748-->00:07:35.221
and that second current marker
that we can use to infer whether
or not we have a match for a

00:07:35.221-->00:07:41.428
particular digit or mismatch for
a digit that time will vary by
28 microseconds. All right, so

00:07:41.428-->00:07:47.300
how this would work. What you
do, if you're using this to your
advantage is you would start

00:07:47.300-->00:07:54.007
with some arbitrary key code.
Then you would cycle through the
various values for the first

00:07:54.007-->00:08:00.146
digit, zero through nine, and
you would keep the other values,
the digit values fixed. So you'd

00:08:00.146-->00:08:05.151
go: zero, etc. etc. etc. then
one, etc. etc. etc. and then you
would look at time required to

00:08:08.054-->00:08:13.593
go from between those current
markers to whichever digit,
whichever value for that digit

00:08:13.593-->00:08:19.265
had the longest time delay
that's the correct value for
that digit. All right. So in

00:08:19.265-->00:08:23.136
this example here we found that
the first digit is nine. All
right once we found the first

00:08:23.136-->00:08:29.576
digit we repeat the cycle with
the second digit we use the
digit we just found and then

00:08:29.576-->00:08:34.381
cycle the second digit through
zero, then one, the two, then
three, then four etc. holding

00:08:34.381-->00:08:39.386
the remaining digits fixed. And
repeating this again off until
the fifth digit. So this allows

00:08:42.055-->00:08:49.028
for us to more efficiently
search for, through the
possibilities for this key code.

00:08:49.028-->00:08:52.132
The sixth digit is a special
case, we'll get to that in a
little bit, but the timing

00:08:52.132-->00:08:57.971
attack works great for the first
uh, five digits. Now you might
be wondering how does that

00:08:57.971-->00:09:03.343
actually look on the real world,
umm, and this is how it looks.
This is looking at a zoomed in

00:09:03.343-->00:09:08.348
version of the second current
rise - so the second marker that
we're using - and at the top of

00:09:11.317-->00:09:16.756
the, of the, uh, scope shot you
can see overlayed, different
runs where there was, where

00:09:16.756-->00:09:21.694
there was zero digits correct
and then one digit correct in
sequence and then when there

00:09:21.694-->00:09:25.732
were two digits, the first two
digits were accurate and the
remaining were wrong, and then

00:09:25.732-->00:09:32.172
where there were three
wrong-accurate and then wrong
four and five so as we got more

00:09:32.172-->00:09:37.177
digits correct in series we, uh,
extended out our, our time
delay. It's still a problem

00:09:39.379-->00:09:44.451
though because this lock
includes a feature called a
penalty lockout. if you enter

00:09:44.451-->00:09:49.289
the wrong keycode five times in
a row it will lock you out
preventing any additional

00:09:49.289-->00:09:54.294
attempts for ten minutes. Now
and you can't get around this by
pulling the battery, you can't

00:09:54.294-->00:09:58.932
get around it by, uh, you know,
accelerating the clock or
something like that. You really

00:09:58.932-->00:10:03.403
have to wait ten minutes once
this has started. So I thought:
well, I wonder if you can

00:10:03.403-->00:10:07.907
prevent it from starting in the
first place? I wonder if perhaps
we could do something like cut

00:10:07.907-->00:10:12.912
power to the lock prior to
writing this incorrect attempt
count to EEPROM and so I did

00:10:16.516-->00:10:21.221
some investigation and got
another STM8 just like the one
that is in the lock and fiddled

00:10:21.221-->00:10:25.692
with killing power to it at
various times. What I found was
actually even better. So it

00:10:25.692-->00:10:30.697
turns out that if you start a
write to an address in the
EEPROM on the STM8 and then you

00:10:35.034-->00:10:39.739
kill power to that
microcontroller between 500
microseconds and 2 point 5

00:10:39.739-->00:10:44.511
milliseconds after the start of
that write what you'll be left
with is not the original value

00:10:44.511-->00:10:49.516
not the new value, you'll be
left with zero. And so the
reason this works is because in

00:10:53.286-->00:10:58.825
EEPROM, in flash, before you can
write a new value to a
destination that already has a

00:10:58.825-->00:11:03.763
value you need to erase that
destination value and on the
STM8, a little unusually, the

00:11:06.466-->00:11:11.938
erase value is zero. Oftentimes
on other EEPROMS and flashes
it'll be FF but in the STM8 it's

00:11:11.938-->00:11:16.943
zero. And moreover the, uh, lock
firmware, appears to treat zero
as a valid value so, uh, all we

00:11:20.613-->00:11:27.220
need to do is kill power to the
MCU between 500 microseconds and
2 point 5 milliseconds after the

00:11:27.220-->00:11:29.222
write to that incorrect attempt
counter starts. Alright, so,
turns out, even better, we know

00:11:29.222-->00:11:34.227
exactly when to do that. That
second current rise we use for
the timing attack ends up being

00:11:43.002-->00:11:49.976
the start of the write for the
incorrect attempt count. So if
we key on that. We can

00:11:49.976-->00:11:56.549
accomplish our goal, we can,
first of all we are able to get
the voltage low enough quickly

00:11:56.549-->00:12:02.655
enough if we start at a somewhat
lower voltage - but still valid
- we can actually get below the

00:12:02.655-->00:12:08.695
brown out voltage for the
microcontroller in about 600
microseconds so we know we can

00:12:08.695-->00:12:13.299
get there once we start the
question is then when to start
that power, cutting that power

00:12:13.299-->00:12:20.206
to the lock. And, since we have
that current rise, from the
start of the EEPROM write, key

00:12:20.206-->00:12:26.446
off of that, takes us about 500
mili-, uh, 500 microseconds to
recognise what's happening and

00:12:26.446-->00:12:32.986
to then begin cut power to the
lock with a with a FET, a very
fast switch. In total, 1 point 1

00:12:32.986-->00:12:39.025
milliseconds from when the write
starts to when the lock is below
the brownout threshold voltage

00:12:39.025-->00:12:45.531
once it's below the brownout
voltage any pending, uh, part of
the EEPROM erase cycle or write

00:12:45.531-->00:12:51.237
cycle will be aborted, um, 1
point 1 milliseconds, of course
is well within our window

00:12:51.237-->00:12:56.909
between 500 microseconds and 2
point 5 milliseconds. So you put
this all together and what this

00:12:56.909-->00:13:01.848
lets us do is have an infinite
number of attempts to guess the
key code you go through, say,

00:13:04.917-->00:13:09.922
four attempts or five attempts
and then you reset the key, the
invalid attempt count back to

00:13:12.058-->00:13:17.063
zero. So, this allows us to,
umm, to both get the sixth digit
and also, more efficiently

00:13:21.034-->00:13:25.038
search for the first, for the
first five digits. The reason it
helps with the sixth digit is

00:13:25.038-->00:13:31.044
because we just want to brute
force that. We want to go
through and try, knowing the

00:13:31.044-->00:13:35.915
first five digits, all the
possibilities for the sixth
digit so we'll just go through,

00:13:35.915-->00:13:42.088
try each of them, and umm, every
periodically we'll reset the
invalid attempt count and just

00:13:42.088-->00:13:47.593
keep going through all ten
possibilities for that sixth
digit. All right, so, attacking

00:13:47.593-->00:13:51.631
this lock I couldn't, I couldn't
just do wirth a resistor. So the
first lock that I used had a

00:13:51.631-->00:13:56.369
scope and a resistor and that's
like, like uh, first week of
freshman double, you know,

00:13:56.369-->00:14:01.274
electrical engineering class
sort of stuff. This is a little
more complicated in that I need

00:14:01.274-->00:14:05.144
to build a custom board to
support this. This has a
microammeter on it, this has

00:14:05.144-->00:14:09.882
some support circuitry to allow
us to emulate key presses, this
is essentially just allowing us

00:14:09.882-->00:14:14.721
to, um, prevent - present
different voltages to the lock
emulating a key - certain key

00:14:14.721-->00:14:21.194
values. Uh, also the power
supply and the control, uh,
mechanism for us to cut power at

00:14:21.194-->00:14:26.199
very, uh, very precise time. So
we, then look at the algorithm
used in the lock. It's very

00:14:28.835-->00:14:33.539
similar to the um, what we
described earlier, we first used
a timing attack to find the

00:14:33.539-->00:14:37.944
first five digits we'll go
through and have - try all
possibilities for the, all ten

00:14:37.944-->00:14:42.749
possibilities for that first
digit value whichever one has
the longest time delay that's

00:14:42.749-->00:14:47.687
the first digit value the actual
first digit value use that first
digit value and then try cycling

00:14:47.687-->00:14:52.225
through the second digit values
whichever of those has the
longest delay that's the second

00:14:52.225-->00:14:56.229
value and so on and then we,
like I mentioned before we'll
bruteforce that sixth digit by

00:14:56.229-->00:15:02.802
trying all ten possibilities
there. All the while resetting
the um, lockout attempt count

00:15:02.802-->00:15:07.807
periodically. So let's take a
look at that. So here we have
the uh, the support board that's

00:15:11.244-->00:15:15.148
blue and we have the STM32
board, that where the, uh,
attack firmware is running on.

00:15:15.148-->00:15:20.686
The STM32 is a little ARM Cortex
STM four with a pretty good, uh
ADC on it. The scope in the

00:15:20.686-->00:15:24.423
background is a log monitoring
the, uh, current consumption.
It's just there for visual

00:15:24.423-->00:15:29.428
effect. Um, as it cycles through
the various possibilities for
the key code uh, it has to do

00:15:31.898-->00:15:36.602
some over sampling. In a real
world uh, environment there's
noise so we want to try each of

00:15:36.602-->00:15:41.641
these potential combinations
multiple times and so for that
reason this video is actually

00:15:41.641-->00:15:46.646
sped up by a factor of ten to
fit into the presentation. Um,
even so, the - the full attack

00:15:50.049-->00:15:54.854
in a fairly robust manner takes
about 15 minutes. Which is a
huge improvement from the

00:15:54.854-->00:15:59.859
potential 3 point eight years
that a naive brute force attack
would take on the lock and, um,

00:16:02.461-->00:16:08.367
as the attack firmware cycles
through and finds the true
values for each of these digits

00:16:08.367-->00:16:13.372
in the key code eventually will
reach the sixth digit it will be
monitoring the buzzer line to

00:16:13.372-->00:16:16.876
figure when it has the correct
code, because the lock will buzz
in a different way depending on

00:16:16.876-->00:16:20.813
whether or not you have entered
the correct or incorrect code
and once it detects a correct

00:16:20.813-->00:16:26.219
buzz it says "oh we found the
correct code and we'll stick
with that" [inaudible] then they

00:16:26.219-->00:16:31.224
flash a little green led and
allow that located key code to
be replayed, um, there's a

00:16:34.026-->00:16:40.800
button on the board and when you
hit the button it would then
replay that, identified key code

00:16:40.800-->00:16:44.604
so that's what's going to happen
right now. There it is, it found
the final digit. The lock is

00:16:44.604-->00:16:49.709
locked you can see me try to
pull it with my thumb, now we're
going to hit the button, it's

00:16:49.709-->00:16:54.714
replaying the key code and the
lock is open. So... [applause]
here we go [applause]. And then,

00:16:57.583-->00:17:02.521
and then uh, after five seconds
the lock will relock itself
automatically. All right. So,

00:17:08.594-->00:17:13.666
you know, having said all that,
umm, burglars like are not going
to bother with this like,

00:17:13.666-->00:17:18.537
they're just going to use a
crowbar or the hydraulic jack
for your garage or something

00:17:18.537-->00:17:21.374
like that. Maybe, if they're
really fancy they'll use a torch
but that's really only like

00:17:21.374-->00:17:27.880
movie stuff. Um, I think the
more interesting, uh, thing here
is, perhaps, applicability to

00:17:27.880-->00:17:33.753
other systems. We see other
systems that have this sort of
lockout, uh, mechanisms, uh, you

00:17:33.753-->00:17:38.591
know maybe phones or other locks
and I wonder if maybe there
might be something similar that

00:17:38.591-->00:17:43.596
could be applied there and, you
know that uh, the shame is that
each of these issues is actually

00:17:46.098-->00:17:50.369
fairly easy to fix in software.
Even the original lock which
seemed like a hardware issue, it

00:17:50.369-->00:17:56.142
could be addressed in software
if they just didn't store the
data, the keycode in clear text,

00:17:56.142-->00:18:00.780
I mean don't store your data in
the clear. I think you know uh,
this, you'd think that'd be

00:18:00.780-->00:18:06.485
common knowledge but I guess
not. So then timing attack what
you could do to mitigate that

00:18:06.485-->00:18:10.389
would be to do the-your
comparison in constant time,
don't abort your search

00:18:10.389-->00:18:15.561
comparison loop early if there's
a mismatch, go all through all,
all though the way, through the

00:18:15.561-->00:18:22.068
end. Um, the EEPROM
manipulation, little more
complicated. The way you'd get

00:18:22.068-->00:18:28.874
around that or the way you'd
defend against this attack is to
assume failure first. So assume

00:18:28.874-->00:18:34.981
that the user will enter the
wrong code and increment that
invalid attempt count first and

00:18:34.981-->00:18:39.852
then, if they ended up actually
entering the right code then
clear that out, enter a zero for

00:18:39.852-->00:18:44.790
that, um, that would still leave
you with the possibility of
erasing it, forcing the erasure

00:18:44.790-->00:18:50.429
of that destination but what you
could do there is treat the
erase value for whatever

00:18:50.429-->00:18:55.635
methods, wherever you're storing
this data - flash or EEPROM or
whatever. Treat that value as an

00:18:55.635-->00:19:00.573
invalid value so, instead of
treating zero as zero you, know,
why not treat that as invalid

00:19:03.075-->00:19:08.080
and you relock it harder. Um.
So, the, I should also disclose
that I've been trying to get

00:19:13.686-->00:19:17.790
Sargent and Greenleaf's
attention on this since February
and they haven't been providing

00:19:17.790-->00:19:22.261
any useful response so that's a
bit disappointing. But I'm
hopeful that they'll go forward

00:19:22.261-->00:19:27.533
and uh, make some improvements
in the future. There are better
locks out there I should

00:19:27.533-->00:19:32.538
mention, the, there's a federal
standard for GSA approved locks,
it's FL, uh, 2740B and this

00:19:35.174-->00:19:40.880
standard is designed to defend
against this sort of attack. So
if you really want a good,

00:19:40.880-->00:19:45.985
electromechanical lock, you
know, I'd recommend some sort of
GSA approved lock. They're kind

00:19:45.985-->00:19:51.157
of expensive though. So, uh,
feel free to email me if you
have any questions. So thanks

00:19:51.157-->00:19:55.761
guys. [applause]