Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/859 Thanks!
All right, let's get started then.
So we really do love our conveniences
today nowadays, inserting a physical
key into a lock is just too much work.
Our lights have to kind of regulate
themselves. It's way too much effort
to hit the switch all the time.
But we forget that this automation comes
with a price and that prices
our security and our privacy.
Our speaker today, Marcus Miller and
Marcus Chater,
are going to talk about a
device that actually had a lot of promise
and was basically brought down by
a very simple implementation problem.
And
there's actually going to be a demo if
you see the hardware over here.
This is awesome.
We're going to we're going to have a demo
here. Everybody else who's not made it to
this talk is going to are going to
totally regret it.
So give it up for Marcus
and Marcus.
Yeah, thank you, everybody, for coming.
I'm still waiting for the sleights.
OK, that's awesome.
So my name is Mark Accommodator, with
me on stage as my colleague Marcus Miller
and to our colleagues who have been
involved with the project are also here,
sitting over there, um, Christian
Cordella and Daniel Bryan.
And all together we are from the security
consulting company Transfix Katie.
So I would first start out by giving
you an idea who we actually are.
So as I mentioned, we are a security
consulting company, so we focus on
security consulting, engineering
and security research.
The company was founded in 2012,
but the security consulting work actually
reaches back to 2005.
And so today what we do
is we do security audits, we
do security audits of Web applications,
software applications.
So this is pretty much what everybody
else is doing as well.
But we have a strong focus also on
embedded devices and
with our hardware security, we can even
go down to the microchip level.
So just to give you an idea, what we do,
in addition to that, we do embedded
in security, engineering and high speed
cryptography.
Second slide, this is the lap that we
have so we can really go down
deep, uh, even to
the top level.
We have a focused iron beam workstation,
a scanning electron microscope to do this
kind of work.
And typical work we do in the lab is
like evaluation of against
site channel attacks or faulty injection
attacks. And then we can even go
to the microchip level by doing fully
invasive attacks.
And our general idea here is that
you have more sophisticated equipment in
the lab and so we can make
up analysis time so we can do an analysis
in a short amount of time.
Whereas a normal attacker who would not
have all these tools has
typically more time to conduct attack.
OK, so now the big question, how
in the hell did we get to garage doors?
Right.
So as you might know, many of
the garage door systems that are out in
the field that are really known to be
insecure, insecure,
because they mostly use static or
very simple rolling code schemes,
there is often no encryption at all.
And for this reason, you can mount
very easy replay attacks
or cloning attacks.
So this is pretty much known.
And in contrast to that,
there is this there's to be a secure
system.
So it uses the well known as
encryption algorithm.
It is a high, um, security
established system in the field.
And if you compare that to the classical
systems that are really easy to break,
it is a big security improvement.
And yeah, to answer the question,
how we actually got to this system
is the two of our security analysis,
uh, both sitting here,
they have the system at home.
And so they they were asking
the question, um, is
the system really secure?
So is the system implementation
secure in practice?
Does the system really use the as
algorithm? And is the algorithm used
in a secure.
How is the key material generated,
how is it used, um,
is the key material individual or
is that may be shared key material among
different systems?
What do the messages look like on
the RF interface?
And last but not least, the question,
does the system adhere to the Kirkos
principle? So if an attacker really knows
exactly how the system operates
and the only thing he doesn't have is
the key material, then the system
should still be secure.
And this was the point where we decided
to conduct a security audit.
So how do you start a security
audit on a system like this,
on a wireless system with all these
transmitters and the receiver
that's typically agaric?
And so we started off with
the transmitters, so we already had
a few of them.
We also obtained new ones.
And so what we had is we
had different models, we had
different manufacturing data.
So some of the old hand transmitters
that we had were already bought in 2015,
whereas the newer ones were bought in
2017.
And so in general, we can say that our
analysis then will also cover a broader
range in terms of the different
models and the manufacturing dates.
So to start out, what we did is we
conducted an RF signal analysis
from the system Manuell.
We already knew that the system operates
somewhere in the eight hundred sixty
eight megahertz range.
So we used the software defined radio.
I played RF in this case, and
our goals at this point were just to find
out what is the exact frequency
the system operates then what
is the modulation scheme that the
system uses to transfer the data?
What is the channel coding?
And after we have answered all these
questions, hopefully, um,
decode our frames.
So if you have one of those
systems, um, what can you do
to find the frequency?
It's actually pretty, pretty easy.
So you can just use the radio tools.
We also did that.
We perform the spectral analysis.
So we tuned our software defined
find radio to this eight hundred sixty
eight megahertz with enough bandwidth
so that you can really see the signal and
then you just do a waterfall
plot. And what you will see there
is if you press on the transmitter,
you will see something like this.
So this is just a normal waterfall
diagram.
It shows the spectrum over time.
And here we can see that there
is a signal with
a frequency of eight hundred sixty
eight point three three oh megahertz.
So we have now already identified
the frequency. That's good.
But what we also see is on
the left and on the right side, you can
see those peaks.
So when the signal is transmitted,
it uses actually two
frequencies and it switches between them.
And this is a very strong indication
that frequency shift is used.
So the idea of that is that if
you have a zero bit, you transmit a bit
of a lower frequency and if you have a
one bit, you transmit a bit of a higher
frequency. Pretty simple.
So we already know that Fishscale
modulation was used.
Now, the next step is we want to
know the channel coding.
So if we modulate the signal
and we have the data bits, the data
bits are still in a channel coding
scheme and we need to find out which
scheme is used.
And so what we did is we had a look
at the signal and in the
first step, it was necessary
to get to the to the right symbol
rate.
And the typical signal starts
with the synchronizing block.
So this is just a very simple waveform
with an alternating high and end
and low signal all the time.
And it allows the receiver to synchronize
it, symbol to the transmitter.
And we did just the same.
So it allowed us to synchronize
on the signal.
There's a picture where you can see that.
Um, so on the left side here,
you can see the synchronization block.
And after that, there's the data block.
And once again, here we are in the time
domain. And here you can also easily
see that first came all the heels.
So we have this long periods
and we have signals with the short
periods.
So this is fishscale modulation.
And if you do a Google search
for a new radio
FSA, the modulation, um,
there's a lot of examples of stimulating
blocks.
And so, um, we had
a look there what how the
how the typical modulation scheme looks
like. And then we added a few more
blocks that are specific to our system
and we tune the blocks to our
system.
So after all, we wanted to analyze
the particular system.
So also the blocks have to
be particular.
Specific?
Um, yeah.
So we came up with this block, um,
we already cut away this initial
synchronization block so that we just
end up with the demodulator data bits.
And once we have those, we can hopefully
analyze them and find out what
the channel coding is.
Yeah, we just did that.
We analyzed to capture file.
And interestingly, what we could find
in there is there were always
sequences of symbols,
but it was always a zero, followed
by one or one followed by
zero and.
This indicates that Manchester coding is
used, I have here a very
simple picture from Wikipedia,
so it actually takes two symbols to
transmit one data bit.
And if you have, for instance,
uh, first a symbol of one
and then a symbol of zero, the data
is one and vice versa.
If you first have a
symbol of zero and then a symbol of one,
the data, it is so pretty
easy.
And at that point, it allowed us already
to, uh, to try decoding
the RF frames that are used in the
systems.
So we wrote a Python script.
We use the radio framework once
again. Um, our assumption
was also that typically at the end
of an hour, a frame there has to be some
kind of checksum.
After all, the receiver has to know
all the. Yeah, the receiver has to know
whether the transmission was
correct, so whether there were any errors
or not. And it can determine that
by computing a checksum
and then comparing it to the checksum in
the packet.
Yeah. And what we came up with can be
seen in this table.
So we noticed we had like
nine different transmitters at
the end and we pressed the different
hand transmitters and we just had a look
what, uh, how the RF frames
looked like.
And so at this point, we could see that
the frames always started with
Iida and OIK 70 or
50.
After that, there was the serial number.
So it was a four byte value that
was individual transmitter and it didn't
change at all.
Burhenn Transmitter.
After that, there was the encrypted
data field.
So we knew that the system uses a
synchrotron.
And this there was this very large blob
that changed each time.
So obviously that has to be the encrypted
data. And we also assumed,
but really weren't sure at that point
of time that the last byte is probably
the check somewhere.
OK, now, so we have managed
to decode they are afraid we have a
pretty good assumption of what the signal
looks like.
But still, our main question is how
does the system operate?
How how does the how does
the encryption scheme work?
And so our next step was to,
uh, hardware analysis.
So we just opened up a transmitter
and here you can see this on a picture.
So it's just, um, I think
it's from from one of those transmitter,
very pretty small.
And if you open that up, you have this
PCB, you can find
different chips on there.
And you can also see that there are a lot
of test pits.
And in fact, uh,
the chip with the little stick on it is
a microcontroller.
So in general, we had a look at the
chips, at the chip markings.
Um, we could find out that there
is a, uh, transmitter I see
in on the PCB, the
six twenty or
twelve thirty radio chip.
So there's a public data sheet for that.
So we knew what kind of chip it is.
However, more interestingly, was the
microcontroller.
After all, the microcontroller contains
the actual system implementation.
So if we are able to analyze the
firmware, we will also find out
precisely how the system works
and whether it contains security
vulnerabilities.
And in our case, we had a look at the
microcontroller and what we
could see there is the microchip logo.
So the logo of the manufacturer,
uh, microchip.
And so we assumed that it is
probably a pick microcontroller,
but unfortunately, the model type of the
chip. So the exact, uh, microcontroller
type was not written on the chip package.
Instead, there was a very long
manufacturer code.
So you might notice that if you
if you buy a microcontrollers in large
quantities, sometimes you get your own
chip markings.
And obviously we had something
like this. So we really didn't know what
kind of microcontroller we have.
We only knew that probably it is a pick
microcontroller.
But what else did we know?
We knew that the chip has twenty
eight pins.
We knew that the chip is an AKUA
package.
We also knew that the chip is probably
older than three years since the system,
the biosecure system has been on the
market for a long time
and only recently
Microchip acquired Atmel.
So it could be possible that in the
future there might be Atmel chips
that now have a microchip logo on
it on them. But in our case,
this cannot be the case.
And from the PCB, we knew that
ground is on pins five and sixteen.
And as you saw in the picture before,
we saw all these test pins.
And so we also assumed that the test
points on the PCB probably
also go to the programing pins
of the microcontroller.
So to identify the controller,
um, the first thing we came up
with is just.
Doing a simple search at a component
distributor.
So we searched for the manufacturer
microchip, we searched for chips
with twenty eight pins and chips
that are available in the queue event
package.
And the results were only for
four different models.
So they pick 16 F 18 F
24 events, 32 F.
And so at that point, from those four
candidate series, we
started to look into the data sheets
and as it turns out, to pick 24
and pick two is not only a pretty large
microcontroller, um, but
it would also need a ground on PIN
24.
And this is something that was not on our
PCP.
So, um, we assumed
that the pick my, uh, microcontroller
must in fact be either a pick 16
or 18 F series.
So what we did next is
to identify the programing pins,
so if you want to go to the program
or pick microcontroller, you need
you need the programing pins,
not our PGD, PGC,
and then a supply voltage.
So we did The Uncrowned and
all of the pick 16 F
series and pick 18 F series
in this 28 PIN package.
They have the programing pins at the same
location.
So it's easy.
And at that point you can just
connect the, um,
the the ticket three program
to the device. So that's like a very low
cost programing tool that everybody is
using to program peak microcontrollers.
So this is the picture
of the PCB and now
you can also see in red marked
in red, uh, the test points on the
PCB and in the table on the right,
we can see that, in fact, the programing
pins have been, uh, connected
to those test pads.
Yeah. So we did a little break board,
break out board to connect the picket
programa.
And, um, yeah, we wanted
to know what microcontroller
we are dealing with.
And the two, um, reported
to us that in fact it is a pick 18
f uh 26 K 20
microcontroller.
OK, so much for that.
But what it also told us that
we already assume that, uh,
that all the flesh blocks are locked.
So there are cord protection bits and
we cannot just read the firmware.
The firm is locked down.
It cannot be read out.
What we also saw is that the EPROM at
this point is not locked.
So we could just dump the EPROM at this
point. But unfortunately, it doesn't
contain the firmware.
Yeah, so we want to do a family
analysis because in the firm where
there's the entire system implementation
and only by conducting a family analysis,
we will know how the system operates
and whether the system is secure.
And yeah, from it's locked,
the locking pits on the on the pick
microcontroller are typically implemented
in a form of a security fuze.
But yeah, since we were
in the situation that we could not dump
the firmware, um, the issue
would be more or less that we cannot get
the firmware out.
And so we would have to go back to
security by obscurity.
We would have to trust the manufacturer
that the system is really secure because
we cannot dump the phone.
Yeah. So what we did is we
have had the security lapse.
So we have a lot of methods
that we can apply to to even
conduct a security audit in
this case.
Now, our first question was, how is
the security use logic implemented
on the pick 18 F microcontroller?
How does it look like?
What are we up against?
What do we need to get around to
be able to extract the farmer?
And our approach in this case was
to do and I see the capsule,
so to open up the chip and
then do a rough microscopic analysis.
So here are some pictures.
So rather easy process.
So you just dissolved
the chip.
And then we follow,
uh, what chemicals?
The capitulation process.
And in the last picture, we can see that,
uh, the chip has been opened up.
It would still be functional at that
point, but we can visibly see
the Dynel.
So the next step, um,
we used to Chip and we
we had a look at it in a microscope.
And this is what we could see.
This is a pick F microcontroller.
It has a very large Flesche area
to SandstrÃ¶m.
It hasn't EPROM.
And on the sides on on the right
side is the area where we suspect
that the security fuzes are.
Big question.
Why do we suspect that there
are other security fuzes?
Yeah. Um, on today's microcontrollers,
it's often very easy to spot them because
of those little metal shields.
So in the old days, there was, uh,
there was an attack where you could just
reset the security fuzes
by using UV light
so you could erase the security fuzes
with UV light.
And after that, you could just dump the
chip.
And, um, as a countermeasure,
manufacturers came up with those little
shields.
So now you can use those little shields
to spot the potential areas of
the security forces.
OK, so we knew at this point
what we are up against, what we need to
do. And we were sitting
in the lab and exploring different
options that we could do.
And, um, yeah, so
the first method that came to our mind
is the chip is already,
uh, we could do an invasive circuit
at it.
So we have a chip already.
And, um, the approach
would work, uh, in the following
that we that we would have to identify
the security Feuilles logic so we already
know where the security fuzes are.
We would have to to
look a bit deeper into that to find
out how the logic works.
And then we could bypass the Security
Fuze by using, uh, by applying
a circuit at it.
OK, so that's a method.
Um, and the big question was,
uh, what would be the advantage of it
and what would be the disadvantage
that vantages.
Yeah. If you can do that,
you have a high success rate
disadvantages.
We didn't do an analysis of the
picaridin before, so we
didn't have a recipe at hand.
And so it would have taken us a long
time to figure out how the
Security Fuze logic works.
Yeah, so to give you an idea
how hot it how that method would
have worked.
This is our fifth machine
and this is what you can do with it.
So it's like a solar ring.
Iren, for a chip on this picture,
you see an example of another chip where
we did a circuit.
Edit in general, the machine allows
you to cut tracers
and also to deposit new tracers.
So in the case of the pick a controller,
we could have just cut the
output rail of the Security
Fuze and then connect it to
video ground.
And so we would have a fixed output
and bypass the Fuze,
the next option we
explored. So we did a bit of more
research and there
is the well known panic attack.
So I told you before that now there
is this countermeasure where the
manufacturer puts those little metal
shields in order to avoid UV light
getting down to the Fuze.
And, um, Bunnie Huang,
um, he he he wanted to do this
on a different type of, uh,
controller.
And what he found out is that if you use
the UV light at a very steep angle,
it can actually go below
the shield, bounce up again, bounce
down again at the field and so on and so
forth.
And that will be enough UV light in
order, um, to erase the Fuze.
OK, that's nice.
So the advantage of that would be our
chip is already open and it's it's
rather easy to conduct.
So we could just ride these advantages
that, um, Bonnie
did the tech on on a different chip
model. So we really not we were at
this point really not sure whether we had
the same Fuze type.
So there's not a Fuze type.
It's called A. Fuze.
And instead of getting cleared
by UV light, it's getting set by UV
light.
And, um, what you also have
to do is you have to cover the flash
memory, for instance, with a permanent
marker or with a little electrical tape.
Otherwise you will also erase the flash
memory.
And so at that point, we were a bit
worried that we could damage the chip.
And, um, it was still unclear
to us whether the approach worked.
Next thing is op2 covered
today in a few talks is voltage
glitching.
So we have a voltage glitch
amplifier, but we can, uh, we can conduct
Klich, uh, attacks
at very, very short pulses and high
current so we could try
to clinch the chip in order to extract
a further advantage would be
easier to conduct disadvantages.
We have really no idea if this approach
works, um, on the ATF
and we would have to find the parameters
first.
Yeah. So these are the methods so far
that we explored.
And after doing more research,
we also found the easy way.
So the easy way that really everybody
with the technical knowledge can
conduct at home without
all these fancy tools.
So there is a really a trivial
design issue in the picture.
Eighteen F security of use logic.
And the design issue is that the
ATF controller, it has
five memory blocks and
each of those memory blocks has
a separate security pit.
So separate locking bit.
And what you can do is you can erase
a locking bit of one block, therefore
you will also erase the content
of the block.
But the remaining blocks, the programing
will stay intact.
So you can just like upload
a dump code to this block.
And then by using the same code, the, um,
code will extract the remaining blocks
that are still locked.
And this is, in fact, even being
presented at the CCC at the
2073 in 2010,
already by Milosh Mary Agnes Talk
Heart of Darkness, exploring the
unchartered backwaters of hit eyeglass
security.
Yeah, so in order to do this,
we implemented a very simple
pick from the extraction tool, so it was
just a little breadboard set up
the Houston FTI board.
So one of those USB to serial
converters and we wrote a bit
of of, uh, of a software
tool. So it was just a small software
script. So our set up
then allowed us to directly talk,
uh, with the pick microcontroller
programing.
So this is what it looks like
on this pick 18 F when you start out,
you have five memory blocks.
So the first block is to put
block. After that you have the first code
block. It's a bit smaller because of the
size of the block.
And after that you have the additional
code blocks and all of them are locked
right now.
And so what you do is you
remove the cockpit, for
instance, in this case here of the book
block, and therefore you also erase the
board block, as you mention, the
other blocks remain intact.
Then we create a little damp
coat, we program it to the good,
to the boot block.
And once the ship is powered
on, our block will execute
and it will just happily dump the
remaining four code blocks
and after that we will have a partial
dump of the microcontroller.
Even so, it is locked.
However, the only thing we don't have is
the bootblack because we overloaded
and the content obviously is irrevocably
lost.
OK, so we do.
What do we do at that point?
How do we even get that?
Yeah, it's easy. Just take another pick
microcontroller with the same programing,
so start all over again, repeat the
process.
So this is what we did.
But this time, of course, we have to
erase another code block.
Um, you used to dump code again
and now the dump code can be used
to also dump the boot block.
However, keep in mind that the execution
starts at the block.
So we don't know exactly,
um, where at
what point in our block, um,
there is the destination from a
form of our Trump instruction.
So we do not know exactly where execution
jumps into our block.
And so what we can what you can do there
is you just use a knob slight,
um, like from from
buffer overflow stay a very well
known there. And at the end of the knob
slide you have your time code.
So that's the only difference.
And after that you have two partial
dumps of the picks.
You combine those stumps, then you have
the, uh, the full firmware dump
and then you can reflect
those two pick microcontrollers again
and they will have the original
programing.
So at this point, we had extracted the
firmware and we
could start doing a firmware analysis.
So for this, we use the well known either
pro tool.
It, uh, it supports the pick
architecture.
And yeah.
And this way we analyze the firmware
to find out how the system operates.
So the firmware analysis provided us
with a very deep implementation insight.
So we could, uh, we could confirm
how the checksum is computed
and that in fact the last byte is
a check. Some of we knew how the RF
protocol works and we could also obtain,
um, how the encryption, uh,
methodology in the system works.
So to give you an idea, this is the
result of our analysis.
This is the cryptographic scheme and
key generation that's used in the
secure system.
So on the left,
you start out with the serial
number. The serial number is individual
peahen transmitter.
And at the heart
of the encryption algorithm,
you have a 128
algorithm.
And around that, there's a bit of
magic happening, which we believe
is a countermeasure, a whitening approach
against such attacks.
And on the left, you have
a random seat and the entire
block just generates a new random
seat. However, on the right,
there is a static value that is shared
among all the transmitters.
The random seed is used as a key
and it outputs the long term
communication key.
And subsequently, this key is
always used to encrypt and
decrypt wireless frames.
So if we combine that with what we
discovered by doing the RF
signal analysis is, uh,
yeah, this is what we receive
and we know the serial
number, the serial number
is transmitted in the clear.
So we have the input to this,
uh, to this scheme, the
serial number input.
Next thing is, we also know the
static value, static values contained
in the firmware, and that is shared among
all the transmitters.
But we also know is, of course,
how the encryption with the algorithm
at its heart, how it works
because it's implemented in the former.
And what we found out is,
um, yeah, we have the
initial random seed and
of course, the initial random seed has to
be in a transmitter.
Unfortunately, what we found out is
that the very same initial random
seed is used on all the
transmitters that we analyzed.
So in other words, we had all necessary
data to compute a communication
key from a serial number.
Now, how can we attack this one
ability to do an
attack? You can, for instance, use a
low cost software defined radio
such as the CCC radio.
We will demo that in
in a few minutes or the heck RF.
And in our case, like I mentioned, we
used the CCC radio.
We were visiting the CCC camp
2015 and it
was available for free.
There is a conference.
So what you do to perform the attack
is you record the RF
transmission from an
biosecure transmitter one
time only to you only
need to do it one time and so
you receive a wireless frame.
So by now you should know how
the frame looks like.
And in the next step,
you use the information that you have
obtained from the firmware analysis
and from the RF frame.
It looks like this, so we really
know everything that
we need to compute the
communication key.
This is what we do in the next step
with computer communication, key
candidate, the candidate is
correct. If we decrypt the
encrypted packet and it has the known
plaintext structure, otherwise
we will repeat that process.
Why do we have to repeat the process at
all? Yeah, repeating the process
is necessary if the user has manually
generated a new so the
system offers this functionality.
And if a user has done that, maybe we
have to repeat the process for one
or two times.
And after that we know the
long term communication key,
we can decrypt the
encrypted message from the wireless
frame.
Um, we can increase the
contained count up to.
Um, just buy one and
then encrypt the message again with the
long term communication key
and in the last step we use the CCC
radio, for instance, um,
to transmit the frame.
Yeah. And for that, um, we have
prepared a live demo will hopefully
work. And I would ask the video
guys to switch over to Marcus.
So thank you for
today's demonstration, we built a little
set up. Um, this is actually
the rail of a garage door opener.
So this would be mounted on the ceiling
of your garage and it moves
up and down the flag over there.
Down here is the operator, which
is, um, which has the built-In receiver
for the radio.
And we can actually operate it with
a remote.
So to.
If you like.
Let's say that Barack Obama.
OK, to start with the attack,
we have a sniffer.
Which listens for any radio
package in the air, so I have a remote
that's not thanks to the door, so it
won't open, but we can see
packets coming in.
So if any one of you has a receiver,
he could press it now and
we would see the packet.
Yeah, there are some, so
thanks for sharing your keys.
It's very nice.
So, uh, dignifies
configurator for today to stop
when we get the signal from
the, um, entrance
transmitter with the correct serial
number. So if, uh, Michaels
presses the button again.
The door will open and we get, um,
the package we need for our calculations,
so this would be the packet and
now we have a script that calculates
everything we need.
So appears to pick out.
We get that as input for
our script.
Um, it shows us the serial number
and it calculates the communication key.
Uh, it decrypt the package,
uh, which we do not show because,
uh, we agreed to not disclose the
structure of, uh, packet.
So we just showed the counter value,
the current count, the value.
Uh, we increase it by one,
then we can encrypt the packet
again with the key and
we, uh, frame it and put it into a frame.
So it's, uh, ready to be transmitted.
So with another script, we can
transmit the packet with our radio.
So if I press the button, the
door should open without
my kids doing anything.
So let's see if that works.
And now we can again
start up the and see what happens
if Marcus presses the button of his
remote again.
So we actually get the packet and it's
exactly the same as we calculated.
And in addition to that, the door didn't
move because it just got
the packet and it doesn't work to replace
the attack. So the counter
has to be counted up one more time.
So if you press the button again, the
double move again.
It works again.
OK, that's for our live demo,
and Marcus will continue with
our impact assessment.
Thanks.
But can you switch over once again?
Yeah, thank you.
OK, so after we found out,
uh, the, uh, the winnability, we
wanted to do an impact assessment
as well. So what we did is, uh,
we we we did an observation
and we we saw that the serial
numbers of the, uh, of the of
the same model had transmitters
that we bought at the same time
were close to each other.
So we made the assumption that
there are sequential, uh,
serial numbers.
And by having a look at those serial
numbers, our assumption is that
there are probably millions of devices
in the field.
But of course, this is only our
assumption how this serial number,
uh, scheme works.
And we are really not sure if the our
guest is correct.
Next big question is how can we
fix the vulnerability?
Yeah, it's actually rather easy.
Um, as I mentioned, right now,
all the hand transmitters to share the
very same initial random seat.
And the solution, the security fix,
is just that each hand
transmitter would need to have
its own individual random
seed value.
And since this random seed value
is, in this case, no longer than
shared between old hand transmitters,
and Ataca would also no longer
know the initial random seed and
he would, uh, need to start,
uh, like something like a brute force
attack on this random seed.
Yeah. What did we do when we found
out about an ability, um,
as it says here, in case of vulnerability
disclosed responsibly?
So we did is
we follow the responsible disclosure
process at the beginning of
October. We involve the Austrian national
search team as a coordinator.
And we reported the security
vulnerability to them, including
our security advisory and including
the suggested security fix so
that the manufacturer can fix the issue.
And at the end of October,
we actually received, uh, confirmation
from the national soccer team that the
manufacturer has received the
information.
And in fact, he has also understood the
security problem.
Yeah, after that, we had various
email and phone call exchanges with the
manufacturer.
And at the end of November, they also
visited us in our lab and
we presented the winnability once
again and also that suggested
security fix.
And in December, we also received
information from them that that
they have now implemented a
security fix and that they are currently
in the testing phase.
Yeah, to conclude to
talk, um, we presented
a viable methodology that can
be used if you want to
analyze, uh, wireless RF system,
uh, something like similar to this one
that, for instance, also uses
microcontrollers.
Um, of course, we believe
that if you are, uh,
a manufacturer and and you create
something like like this, so you
won't really want to have a secure
system, we believe that is important
to do independent security audits.
Um, so they can be really an
essential tool to achieve a high level
security, um, because
then, you know, you have this external
viewpoint and if vulnerabilities
can be found, you can then fix them
at an early point.
Yeah. Besides, if it
comes to hardware and hardware
security, it's also pretty
good if you have a hardware security lab
at hand. So as you saw, you
have a lot of methods that can be used.
So it's not that you have a system in
front of you and you want to do a
security audit and then you say, OK,
um, now I'm stuck.
I cannot read the FERMA.
I cannot do a security audit.
And so if you have more options, it's
just easier.
Well, yeah.
You also saw that we follow the
responsible disclosure process.
So in addition to following the process,
we also try to support the
manufacturer, uh, in
understanding and also in fixing the
vulnerability.
Yeah. And last but not least, we
will also publish the security advisory
today after this talk.
We already have KVI, ID
and the CBO score,
and in this case, the CBO score
is pretty high.
Um, and we believe it is also
a significant, uh, vulnerability.
OK, so that was
it for our talk.
I hope. I hope you enjoyed it.
And if you have any questions.
Yeah, so if you have any questions, we
have four microphones as one, two,
three and four line up behind
those questions just
to define what a question actually is,
is like one or two, one or two sentences
that actually end with a question mark.
It is not your life story.
And with that, I'm going to go to
microphone one, please.
Yeah. Thanks for sharing this inside.
You said that the manufacturer
has announced a fix for that.
Does that mean customers are supposed
to buy new devices or
will they be able to update them
or have them exchanged?
We really don't know what they have
planned, but we just received
the feedback that there is a security fix
now. So I think it will be really up to
the manufacturer, how
the how he how he will interact with the
customers.
So the Internet has a question for us.
Yes. And the first question is
one that occurred pretty early during
your talk and regarding your
reverse engineering work, because
CIBM user noted that it looked
pretty expensive from a monetary
and timely point of view, and he
wants to know who paid for it.
Yeah, this is this work was actually
done as a fun project.
So most of the of the of the work
that we do is paid work and typically
it's under non-disclosure agreements.
So in this case, I couldn't stand here
and and and and to talk on that.
So this was just a fun work and it was
not paid for.
So microphone one,
a great talk.
How many of these garage door openers
actually use some form of encryption?
It's something exceptional or is
is the standard?
I think, uh, it
it is, uh, that,
uh, that the German system, since it
uses a yes, it's it's
really an exception.
So the typical systems that we saw.
So, uh, few other guys I know, they also
have garage doors at home.
And of course, we looked at them with
a software defined radio.
And yeah, really typically you
can find like, uh, static
messages there.
There's a static code.
You just do a replay attack and there is
nothing. The door goes up.
And so this is something that we really
don't have here.
So I would really say that in general,
the majority of the systems
is probably rather weak.
Thanks for your microphone,
too.
So my question is, after
you broke into the systems, maybe you
play out with the counter so
that you can lock the door forever,
maybe, or it's at the counter
to the low value or much higher.
Yeah, yeah.
In fact, you can do that.
So there is, uh, there's
this accepted counter value and
of course, the, uh, the receiver, in
order to avoid replay attacks,
it has to move discount
window forwards.
And if you do that by performing
an attack, you can
move it, uh, forward
way too much.
And then you can press for like
hundreds of times on the hand transmit
and nothing will happen.
We had that right, uh, right before
when we did the stage demo, I pressed
the hand transmitter.
And since the frame had been used
already and the counter where you had
been used already, it didn't work.
So microphone one, thank
you for your work.
Sorry if I misunderstand, but so
the fix principally is to change these
globally static initialization vector
or random seed, the first one from a
static value to a per
device, and thus that kind of purchasing
affair. How does that stop a targeted
attack where the attacker just listens
for a specific individual and waits for
that particular initialization vector?
Yeah, the attacker wouldn't know this
initialization vector.
Where where did it get where would he get
this? The initial random seed.
So, I mean, if the manufacturer
would know the initial random seed in
case, uh, the the seed
would be stored there, then
yeah. Maybe you can you can get the seed
there. But if this
is stored only in the
transmitter, then nobody would know
the initial random seed.
So you would have to like to
have no expression on it and then you
need it. But since you then would have
physical access.
Yeah.
So if I was to purchase the product
and maybe it had a backup key,
so two two transmitters and one of them
went missing, that sort of thing,
they would they would have individual
random, uh, random seed and
not not the same one.
OK, thank you.
The Internet had a question and yes,
D.A. wants to know that
if the seat is random and
does that mean that you can request
a new forms into an existing
systems since the receiver would
know the random sete?
Um, no, you could you could register
them. That would work just fine.
We did not have a look at how the
how the actual, uh, pairing
process works because it is
only done one time.
But, uh, yeah.
In general, uh,
regardless of the seat in there,
there has to be some kind of exchange
where, uh, the key is compared
to the, uh, to the receiver.
So that wouldn't be a problem.
Microphone one.
And the problem was the
not random seat, if you get
random seats, you pointed out the the
only thing that would be
left to crack the system was to brute
force this 80 bit.
Can you give us a hint how much
how much time it would take to do so?
Yeah, 80 pages pretty long.
So even for instance, we
have fun. We have an FPGA cluster
to explore some of these questions.
And we did some some some some
some, uh, similar algorithms
on it. And yeah.
So 80 bits would still take
at least a few months or so.
So we are.
At least
microphone one, again, I
thank you for work, actually, um,
the thing is, when you jam
the garage door with an SDR
transmitter and like,
just record decode
Devore's code from the
transmitter, from the transmitter,
and you just do replay a check.
Will it work or just
from the rolling code?
It doesn't work.
If, um, so
if you would press the button,
you send out a valid frame.
And if this frame never reaches
the receiver, you could use this
frame at a later point of time and
open up the door.
Yeah. OK, thanks.
But the thing is, when the
like when the frame isn't used
by the new frame was sent,
will it the old frame still be active
or no. In this case the frame would
become invalid because you have uh
a new account of value then and
all countervail use before that are
invalid.
OK, thanks.
So the Internet and, yes,
rather popular question, and you noted
that there will be fixes and that
the devices will be updated and
do the other devices updated
automatically or do they do that?
Does the company have to go to the garage
doors? And if they're updated
automatically, other garage doors
connected to the Internet now.
So the needle, the doors,
nor the transmitters are connected
to the Internet.
So we really don't know what
the manufacturer has in mind here,
but they cannot be updated automatically
online.
Microphone one, are there
are there any other findings in the code
that you have dumped, for
example, synchronization code
or something like that, updating
firmware or something like that?
No, we just had a look at at the scheme
that is used.
And since we we we already found
this vulnerability in
in the scheme, how it is, uh, like,
uh, how it is found on
the systems in the field.
We stopped at this point.
OK, thank you.
And I think we don't have any more
questions unless somebody is really,
really quick, so I'm really glad
that my garage does not have an automated
system. And with that, I would like
you to help me in thanking
Marcus and Marcus for this fantastic talk
and make this really count.
Thank you.