Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2573 Thanks!
[Music]
and we will have a 5 minute Q&A in the
end of the talk and the talk is about
nightmares in the automotive uh
security and we have uh Thomas shini
here who is a a p pesta with Automotive
um and he will talk about the
nightmares
welcome thank you so hello everyone I
hope you're not drunk or sleepy I'm
sleepy but uh we will go through it um
so today we will talk about horror
stories in the automotive industry I'm
Thomas trinis otherwise you might know
me as Crow Tom this is the CCC Edition
uh it's been already once uh presented
uh I'm thomasis as I said I'm Automotive
pend lead by day uh in auxilium cyber
security and thanks a lot to this team
for the support and help for This
research and the security researcher by
night uh I like to hack everything
everywhere I don't really care I just
like to hack everything I gets into my
hands and I really love security
conferences for more you can go to my
website there are some specific goals
for this talk uh first of all I want to
analyze the state of cyber security in
the automotive industry I want to
present some unique and hopefully
interesting for you use cases result of
around 100 pentests and research produ
projects in this industry uh endorse and
push more hackers uh to the automotive
industry and educate uh they new the old
and the Bold of this uh industry and of
course raise and highlight the
significance of security related
devices uh let's start with an overview
of the state of cyber security in the
automotive industry and discuss where
we're currently are what is planned and
where we're currently heading and there
are several incidents throughout the
years uh but I still get fascinated by
the quality uh of the findings that get
discovered on the automotive industry
into 2023 still uh some examples from
the last years are some fixed uh code
vulnerabilities in Nissan for example
which is one of many examples of this
vulnerability in the wild steing Kia
with just USB cables I mean okay uh key
vulnerabilities again and again um
remote unlocks of whole vehicle fleets
due to flaws in serus
XM um unlocking and stealing Vehicles
due to easily accessible casses and
really bad internal architectur
something that we will also talk in this
uh speak about in this talk and that's
only a sample uh out of a huge list of
similar incidents in this
sector I don't know if there is a light
in the end of the tunnel but the
automotive industry cannot be considered
new uh the con connectivity in techn
technological aspect of it though is not
so old uh entertainment and constant
need for connectivity are the main
reasons for the technological
advancements and integration in this uh
industry and usually we are talking
about 100 plus year old Industries uh
trying to catch up with some young
startups and this is an example for you
to understand what is the current state
of cyber security this is the BMW i7 and
outside of the common things that you
usually see in a vehicle you see my
whole living room basically all these
things are interconnected all these
services are connected to the internet
and exposed to some interfaces that are
approachable by attackers
eventually uh in order to fight this uh
there are some regulations that get
introduced I don't want to bore you it's
really late I don't want you to sleep uh
basically to go through it really fast
it provides a set of Standards uh that
must be met in order to ensure the
safety of road vehicles uh it requires
operation of certified cyber security
Management systems and in any case in
summary it tries to saap to shape the
completely unregulated mess that exists
until now until now and the big caveat
is that penetration testing is solely
based on the risk assessment of the
target vehicle or the target
ECU uh going into the first part uh I
want to have a discussion about the tier
one Supply ERS which of course play huge
role in the automotive industry uh with
C cars being literally like Legos pieces
of Legos that you construct from
different tier one suppliers in order to
build the whole
vehicle um to start talking about it uh
we need to talk about cyber security
requirements which are developed and
distributed by EMS and it's usually the
engineering requirements uh for cyber
security risk management and the tier
one suppliers should ideally comply to
those for correct and secure
functionality of the supplied
components um if those requirements
unfollowed though is a different
discussion so let's go through some real
life examples that lead to complete
compromise of a vehicle in the most dumb
way possible and the reason for this uh
from my perspective is that several tier
ones are based in countries with low
transparency and weak governance if you
know what I mean uh
and secondly we don't know how clear are
these cyber security requirements in
order to be followed by these tier one
suppliers and then if uh not only the uh
no the OEM but also the pend suppliers
usually have a reactive approach uh to
security testing which assumes that
everything described on those
requirements is followed which leads to
shaping weak penetration testing
methodology uh and test cases with high
probability of losing important parts of
the attack
surface um to start with our uh first
use case and the path to game over we
need to understand a bit what is UDS uh
basically it's one of the application
layer protocols that run on these
electronical control units the computers
inside the vehicle for communication
between them uh in automotive
electronics uh it allows uh diagnostic
function functionality such as reading
and erasing fault codes programming and
reprogramming ecus testing and
monitoring of them it consists of
several Services uh which can be used to
perform specific actions and the Really
common a indication schema is um in UDS
is the security access service or
zx27 which allows elevated access to
unauthenticated to authenticated
users and talking about this service we
need to understand how it works in order
to go on how we eventually uh bypass it
uh and basically sorry basically there
is a client which is us as a tester or
some reprogramming tool and the ECU the
client that wants to be authenticated
into the ECU sends a sid request to the
ECU the the ECU generates a random seed
and calculates The Key by using a random
um like uh an algorithm uh for this
calculation and the secret key it sends
the random seed uh to the client and the
client using the same algorithm the same
secret key has to calculate the
calculated key where they seeu verifies
it and grants access to the client if
they are matching from both calculations
on each
side uh regarding this service and
considering the TR the trend uh of
loosely developed requirements we have
observed several types of outcomes
including slowy authentication
implementations uh weak sources of
Randomness something that I talk last
year in Troopers uh conference and might
talk UDS fing in the path to game over
and back doors implemented outside of
the scope of the cyber security
requirements as an example we have an
extra uh security access sub service
which is with extremely weak security
for some
reason and actually that's the case here
here here we have a real life example uh
on the screenshot on the right and the
same process as we saw uh previously so
we send a sid request uh to the ECU we
are the client we send the Sid request
to the ECU we receive uh a random seed
despite being four bytes uh it's
debatable on if we can crack it and how
long if there if there is a proper
implementation there should be a new uh
randomly generated seed every time in
this case
this seed is always the same every time
we requested we have the same seed and
by testing the first uh the first key
that we sent which is only zeros we
managed to get a positive response the
positive response here is the 67 73 and
the ECU grants access to us and this
eventually is a back door from our
perspective of course there is no
security in this case and while the T
tier one supplier um Supply the comp
components might follow the OEM cyber
security requirement that doesn't mean
that we only need to test by the book as
you saw by enumerating and finding an
extra security access sub service we
found out that we can bypass it easily
without any uh calculation any secret
algorithm or any secret key and we can
get direct access to it by only
supplying zero zeros uh in most cases
several misconfigurations exist ex
outside of the cyber security
requirements the OEM doesn't know or
doesn't want us to know uh so they don't
communicate and the tier ones did uh or
the tier ones did not inform the OEM in
the end which is the Bor use case that
we had now why I don't know uh the
solution from my perspective from our
perspective uh for the OEM is to build
uh more strict cyber security
requirements for the penses suppliers
like us and the researchers is to build
a more robust methodology which which
will cover a realistic amount of test
cases uh don't build it solid based on
the requirements stop thinking only
about requirements builded on the
experience and the attack surface that
you have uh in front of you and of
course educate the client OEM tier one
or anyone else education is the biggest
part here we need the client
understand what is uh what we found and
what can be the severity and the impact
of
it uh moving forward uh everything will
be changed in the end but moving forward
now uh we need to talk about the main
Bridge of connectivity of a vehicle to
the real world uh lately which is the
telematics unit and how many vehicles
get connected in the net in the network
that uh eventually they should not
actually
be um first of all all almost no
vehicles uh SHP anymore without a
telematics unit um it main purpose of a
telematics unit is the secureity update
procedures uh which became a necessity
they are part of the recent the recent
regulations also uh there are several
running services including a remote
Vehicle Management in most cases uh you
can unlock doors you can start vehicle
conditioning and many other uh use cases
that a user might need might not I don't
know
and the tldr is that please consider the
applicable connectivity while designing
the
architecture so now that we got a first
taste of how things are getting
connected let's dive into a real world
scenario of a super car manufacturer
this in this case that push the
connectivity of their pre-production
vehicle uh in order to perform secure
updates a remote man management of the
fleet for personalized support uh of
their clients in this case and as a
first part we have a telematics unit an
ECU handling the cellular connectivity
and the connection to the internet and
this telematics unit is connected to the
main head unit uh over some kind of
interface it can be an rs485 serial
broad Rich which is Automotive Ethernet
or anything else that is applicable in
automotive at this point one ECU is
already connected and considering that
this kind of ecus usually come with
several publicly available services in
many cases including SSS uh you can
understand that this kind of uh over a
risk is not implemented
properly but there are proper
implementations uh limiting the exposure
at the minimum using hypervisors for
example on the head unit to isolate the
exposed system from the rest of the ecus
and the connectivity in the vehicle and
gateways that fil their requests coming
from the exposed unit
but um I don't know if this is the
reality uh because what we can see in
the complete hypothetical in this case
architecture of this vehicle uh because
we are under NDA of course uh the
different domains uh of of this
architecture um are interconnected
between them but the biggest problem
here uh is that there are several
components directly connected to the
head unit as we can see uh on the red
lines red lines instead of passing
through the Gateway for proper routing
and filtering uh of the target
messages is that really an issue
interconnected buses can act as a
stepping stone in safety critical
attacks and gateways are commonly used
for me message filtering and routing as
we said by passing The Gateway as we saw
in the previous architecture results in
direct interception and communication
of can messages and at this point the
target is a use existing on those buses
can be analyzed enumerated and explo
exploited without the assumed
restrictions from the protections that
we
mentioned and getting deeper into our
attack scenario let's remember the UDS
and this time we will use the service 11
which is uh ECU reset which does exactly
what the name implies uh resets the
target ECU uh in different ways with
most important one being the hard reset
which technically performs a complete
power cycle of the target unit in our
experience almost 90% of the target dcus
come with no authentication or
precondition for hard DCU resets which
can lead to several issues uh described
later what is the outcome of this uh EV
super car uh as we can see there are
several ecus that are connected uh uh no
yes so basically here uh we have a
specific domain of of ecus uh that are
directly connected to the to the Gateway
and to the head unit and if we manage to
compromise the publicly accessible head
unit we will be able to access directly
uh a BMS which is a battery management
system an inverter and the whole
batteries that are connected as ccus to
the head unit in this case by supplying
either an ECU reset to the BMS which is
the battery management system or a
combined um ECU reset to all the
batteries one two or three or what
whatever uh is the number of it we can
direct stop uh the communication between
the batteries and the rest of the
vehicle and completely stop the vehicle
which was the case uh as imagined of
course there are ndas we cannot show
exactly what we did with this super car
and also
when we test these components we don't
test them on the actual vehicle most of
the times or in a running vehicle but we
test it on a in a control environment
but I have another example uh where
where the same POC is run uh is running
on a blind spot detection sensor in one
of my rentals which blinks when issuing
ISU reset because you perform a complete
power cycle so the ECU just blinks and
while not critical not as critical as
resetting the but is it can potentially
confuse the driver uh that there is
something on the blind spot or even
create issues with the adaptive cruise
control uh when relying on this system
for turns or or Lane
changes uh to conclude uh while it was a
simple example we were able to see how
bad architectures can lead to some
devastating results Automotive
architecture understandably gets more
complicated due to the need for
connectivity but architecture needs to
be revised in a secure way throughout
the different iterations and not really
in old and outdated architectures used
in vehicle iterations with half the acus
for this I would suggest more internal
buses to be introduced when needed for
proper segmentation and safety critical
and noncritical components and better
designs should be considered from the
first step of production uh when the
actual vehicle starts to be implemented
and developed it's already really relate
uh to change such significant parts of
the
architecture uh moving forward we need
to have a talk about design choices uh
we already briefly mentioned some of the
pitfalls that the industry fell into
because of bad design choices in the
start but let me go let me also give you
some uh juicy insights that will
hopefully you will hopefully
appreciate um understandably uh vehicle
development is way more complicated than
simply design designing an architecting
architecting a vehicle network with
several decisions that need to be made
uh under highly constrained uh budget
and time uh one of the issues that need
to be resolved is the physical space of
the components the actual space that we
will fit everything inside and where are
these components will be placed how they
will fit are they light enough also
weight is a big factor in this uh and
other such questions uh that need to be
answered in order to create an efficient
and working vehicle which doesn't spend
30 L per kilm or has an efficiency of 50
km per charge at this point
manufacturers need to make sure that
everything is secure isolated and
inaccessible to external
buses but what what happen if it's not
um in the car theft incident that we saw
previously uh we saw that a vehicle
getting stolen due to internal B buses
which were accessible behind the front
um the front headlight of the vehicle uh
that is a really accessible place as you
can imagine uh as an attacker can simply
create a small hole behind the wheel of
the vehicle to access the bus and if the
architecture is something similar to
what we saw in the previous section
potentially unlock the whole vehicle uh
and issue an ignition signal which will
start the vehicle and help the attacker
start a road trip which is the case with
this finding here from Ian uh during a
full vehicle pentest though uh we really
often stumble upon some such issues with
Radars sliders and lights being the most
vulnerable ones uh as most of the times
manufacturers connect these components
with internal buses and by combining bad
architecture that we saw previously with
b bad design choices we can have some
really interesting
results taking as an example our
previous diagram we can see that there
are several cameras and
Radars uh in one of the buses of the
vehicle uh this would not be an issue
considering that the bus is isolated
from other buses but because the same
domain we have on the same domain we
have uh the EBS the electronic braking
system it means that it needs access to
the braking and steering ecus which
that's why we see the inter
interconnected bus um inside the network
considering the all previous use cases
are applicable uh we can see the
scenario where due to bad design uh and
attacker managed to get internal bus
access through the front radar due to
bad architecture he can access the
braking system and by issuing an ECU
reset uh to the EBS um to the EBS system
trigger an emergency braking of the
vehicle with potentially devastating
results as you understand if applied in
a highway for example we can see
something like
this
and now let's watch a cute video from A
TRU manufacturer uh which will give us
some insights on the current topic and
how we will move forward in the talk so
on the near side we have a battery
isolator
switch as with everything with computers
on board before we call Action Service
out it's always worth just isolating the
vehicle canning to 10 and let everything
reset itself re-energize the truck and
see if that's corrected your fault
no
relation so completely reated on om uh I
just need to emphasize the battery
isolator and grab your attention a bit
with the video um the battery isolator
is included in many EVS in many fuel
cell cars and other heavy duty vehicles
and it's mainly used for isolation of
batteries for safety concerning
incidents isolator isolation of inverter
um and converters hard reset of ecus and
clearance of folds what this isolation
does like the name implies it separates
the direct current into uh the
underlying components and it actually um
we actually encountered encountered it
several times uh in our pentest and
mainly in heavy duty Vehicles like
trucks buses uh some uh boats and other
uh devic like this that have uh
applicable cus the main question here uh
is if uh should they be accessible in an
unauthenticated manner as we saw in a
video or if they should be
restricted and to answer this question
we are moving to a next chapter which is
the boot loaders um and we need to talk
a bit about it and how some really old
vulnerabilities are becoming new again
and we can use them to bypass several
restrictions
the the boot loader usually in um
electronic control units is architecture
specific um but it can be accessed
through the application layer protocols
uh which is common alongside all the
different architectures that are
applicable the bootloader usually is
used for reprogramming P purposes in
initialization of application section of
the memory read and write from and two
sensitive parts of the memory and
understandably security measures must be
taken to restrict unauthenticated access
uh to these
bootloaders um the hard truth is is that
most of the manufacturers do not
restrict access uh to this part of the
memory uh which as you understand can
supply access to some really critical
functionality on the underlying
systems uh usually even if we get access
to the boot loader uh some of the
sensitive uh services are restricted to
unauthenticated users and most of the
times uh these services are the ones
responsible for secure update of the
unit as an example request download and
upload transfer data and other services
are the ones that are usually restricted
under some security access
implementation um but uh yeah most of
Theus uh use this bootloader uh section
to perform secure update of the Target
and authentication subservices for
reprogramming is different from the sub
service is used in application mode and
other restricted
tasks in this diagram we see a really
simple representation of the application
boot loader parts of the system uh the
normal boot process uh starts from the
boot loader and then ends up on the
application part where our Implement
implemented applications live and manage
the tasks which the ECU is programmed to
performed in some of the cases though uh
we can use the application layer UDS uh
Pro protocol uh UDS and issue session
change to the programming session uh
which will technically D direct us to
directly to the boot loader and usually
uh this session is unrestricted and we
can directly uh uh Supply it and switch
to the
bootloader um in our experience this UDS
session control programming session is
most of the times accessible as I said
by authenticated users uh but what
happened if it's not how do we bypass it
and I don't know if you remember the
service ECU reset but in this case by
supplying an ECU reset a hard SECU reset
we technically uh complete uh issue a
complete power cycle to the unit and the
boot process start from the start what
we can do now is issue another service
which is a tester present which does
exactly what the service impli the name
implies which is stayed that we are
there so we can we don't have to supply
again and again the same uh command the
the same session chains so by issuing
theu reset and then issuing a tester
present we can stay to the bootloader
mode even if uh the swits to programming
session is
restricted so what if even the Su reset
reset is restricted what are we doing
now basically uh on a testment scenario
where we have the ECU on our test B and
we can directly Supply power to it if we
have restrictions on supplying the
service CCU reset we can directly Supply
power to the unit which will act as the
same thing we can just use a really
simple switch we can turn off the power
we can resupply it and then we will have
the same boot process we send again the
tester present we stay in the boot
loader and we have access to all the
unauthenticated um to all the services
that are applicable there and to
everything that opens when we get access
to the boot loader and I don't know if
you remember this but this comes again
into the game uh because what happens if
we have a full vehicle pen test this is
really common and uh with the current
regulations we need to have full vehicle
pen test and if in this case we don't
have the ability to supply power from a
power supply because we don't have the
ECU the vehicle is Con the vehicle is
constructed is full so we need to find
another way and these battery isolators
is one of the things that we use to
bypass these bootloader restrictions the
ECU reset restrictions and the switch to
programming session restrictions so
basically the uh the OEM give us an
option give us a switch outside of the
vehicle which we can use to stop the
power supply and supply it again in
order to get access to the boot loader
and bypass all the applicable
restrictions in this
case
and yeah here's the summary of what was
explained let's go through it we don't
have a lot of time um and now switching
to something that will lead us to the
final and complete compromise of the
vehicle uh combining our knowledge till
now we need to mention my talk from last
year as we said before where I evaluated
security access SE Randomness which is
based in many cases on system clock and
how all vulnerabilities because this is
something that we see 20 30 years now
are becoming new again and it's really
common in the automotive sector
manufacturers this year after my
previous talk uh started realizing and
mitigating this issue in most of the
components and especially big OEM and
tier one suppliers did they
though uh here you can see that we have
the normal boot process and we have one
security the security access service in
order to give us on the application
layer some uh execution of restricted
routines in this case and the subservice
is the 03 we find it uh with enumeration
of the unit and in this case while
enumerating the unit we find out that
the source of Randomness it's the HSM
there is no way to uh basically predict
the seed that we will receive so there
is no way to bypass it in this case but
performing a bit more of a numeration
and uh applying everything that we saw
before by hard resetting the ECU and
supplying power to get access to the
boot loader by bypassing anything even
uh the battery
isolator um in this case enumerating the
boot loader gives us again the security
access service but with a different sub
service 01 which is used for
reprogramming and enumerating further we
see that here we have a sid randomness
of a system clock so basically by
enumerating different um different
sessions of the unit and by applying uh
the different bypasses that we explained
in the previous sections we managed to
find a hidden session which basically
supplies Supply us with weak source of
Randomness and we can eventually bypass
uh and get access to
it um things which are protecting on the
application layer can be usually
unprotected in the boot loader um many
times it's forgotten I don't know if
it's a development team that developed
the boot loader and separate one that
developed the application layer so they
didn't communicate or they didn't follow
the cyber security requirements or it's
externally sourced uh so different Cod
codebase I cannot be sure uh but the
outcome is that it's worth testing all
the available services and subservices
under all available layers on the
ECU and finally we have the story of the
duplicates um what I presented last year
and what I extend this year is the Sid
Randomness fazer module for caring
caribu which is uh an auto a tool for
automating um security analysis of ecus
uh it's mostly modular with several
developed modules and M main advantage
of it is the ease of use main
disadvantage is the inability to easily
alter the lowlevel layers of the
protocol in this
case um as our last use case let's
target the high advv which for safety
critical reasons needs to be easily
isolated from the batteries uh after
enumerating we find out that EC reset is
not available in any diagnostic session
that the available security access is
not backed or of all or vulnerable to
weeked Randomness and that no other
misconfigurations discovered during the
initial
enumeration and in this case we go back
we have our favorite battery isolator
along side a really nice uh relay and by
combining them we can control when the
ECU when uh we can stop supplying power
and start again by using this externally
accessible battery
isolator and what we are looking here is
a heavily edited version of The Mod the
module that I described which instead of
using ECU resets it uses complete power
Cycles from this battery isolator and
fixed delays between the power supply
and the random seed request in order to
prove that the seed is based on the
system clock and despite having all uh
our preconditions restricted as we
discussed uh we get fixed seeds and
basically as you can see because of the
configuration all the seeds received are
the same and based on the system clock
and it's not a small seed it's not
something that we can actually predict
or uh like manipulate it's like a really
big St
that cannot be cracked in our example
having a relay as the source of uh the
power cycle can result in even more
accurate results than by using the ACU
reset service that we discussed
previously with around 20% of duplicate
seeds of our 1K samples we can Rel be
relatively um relatively confident uh
that the target is sourcing the
randomness from the system clock but
even with less if you see a single
duplicate in the such a big string I
don't think that um you should think
twice and in most cases it's easier to
intercept the SE and pre-calculated key
pair from the bootloader accessible sub
session than from the application layer
because it's used for reprogramming
session so if you send the car um to the
testing center or to the service center
and they will reprogram theu it's uh
more applicable that you will able you
will be able to intercept this uh seed
in order to um reapply the key to the
applicable security access
subservice and to conclude uh while
caring caribu might not be the best tool
out there uh it can help newcomers start
and this is how we also started uh
several new automations from my side uh
help the project move forward that you
can check online on the K GitHub project
uh I developed some uh modules for right
data by identifier fazer and another
really important uh Service uh automated
module for complete automation of UDS
enumeration support for new can
interfaces with provider drivers and
different padding or no padding
support and as we reach the end I would
like to briefly mention the differences
between what we perform as pentesters
and what security research on the
automotive industry is and while
reversing firmwares and getting Hardware
access is fun scope is user usually
extremely limited by the client for this
reason we are tasked to find efficient
ways to perform more testing in a
result-driven environment and automation
of task is of tasks is usually our main
priority with direct result the
extension of uh our methodology and test
cases and sometimes they invest them of
our time uh in Automotive Research and
for the client side of the things
Automotive clients need to understand
our methodology and test cases uh and we
are the ones that need to properly
explain it abstract results are not
always good a good way forward and
education is the key for a better
collaboration with developers as there
are no there is no clear standard and
methodology available online in contrast
with mature Industries like web infra
API and
others and here comes the serious finale
and for some food for thought I have
some food for thought for you
I think that um my Approach in the
industry is a bit more romantic in this
case I care about making the world a
safer place and my way of achieving It
Is by doing the best to secure Vehicles
out there and by closely working with
manufacturer manufacturers and by trying
to spread the culture like what we're
doing here the thing is that most of
them especially the OG ones don't really
care about this Vision uh and try to
undermine issues like the ones we
discussed today uh we live in a
capitalistic world in the end and that's
what we have to do we have to build a
product we have to SHP it we have to
make it run so what what I have to say
is that the weight is basically on us uh
the researchers the pen testers the car
hackers and everyone uh in this field in
this audience in this Camp uh to share
the culture and make sure issues like
this are not undermined by the
manufacturers and are not considered
ways of modding but things things that
can directly affect the Safety and
Security of passengers of drivers and of
people in the
streets that's it thank
you well thank you very much we have
some time for some questions are there
yes thank you thank you for
do um I totally get the idea of having a
secret breaker for the security services
because they do that when you have your
simple car they just unplug the
battery yes why don't they just put a
[ __ ] fuse rather than something that
can be reset it has no
real acceptable purpose except what you
do
yeah look unfortunately I don't work for
an automotive uh yes I'm just the
supplier uh and the researcher I do both
things also on my free time and in this
case I don't have a concrete answer uh
usually is because these vehicles the
heavy duty vehicles are not directly
accessible it's not a car that you will
find on the parking lot in the corner of
the street is something that it's
contained in an environment in a fleet
that you cannot easily access it's
probably secured by some company so you
cannot go there and directly do it but
what if you can what if you can bypass
this these physical restrictions so yeah
that's that's the answer I don't know if
I covered you but
yeah do I see any other yeah over
there yeah thanks for the talk um it was
great uh one question so how how do we
prevent the car manufacturers using
these security measures which I hope
will get better and better every time uh
to use them to hide secrets in firmware
like we've seen with the emission um
scandals or these days with driving
automations how do we ensure we still
get transparency about decisions that
are implemented in the firmware while
still keeping the car secure against
Intruders I
guess to be honest I don't know if I
have this answer I think this is a
more more of a political discussion in
general in the it sector not only in the
vehicles if I'm right I think that the
reason we are here in this Camp is
exactly this is also partially privacy
and partially openness and be sure that
what we are using is what we're using
and manufacturers don't hide anything
from us uh in this case I don't have a
concrete answer what I have to say is
that this components are also safety
critical components if something goes
wrong with it people can die and it's
not only about privacy we also have to
think twice when we do something because
if we don't develop it properly or if we
don't secure it properly then it's human
lives in the stake so I don't have a
concrete answer for the privacy issues
because unfortunately it's an issue that
we are trying to fix here but I cannot
fix it by
myself thank
you so I don't see any other
hands oh no we don't have we we have
some time we quite good on
time can you yeah
sorry I have have a question about your
test cases um or your free time maybe uh
did you get the idea to get a little
more creative and maybe used all the
sensors of the vehicles to get try to
get
like yeah artificial inputs that might
trigger ECU reset in another way for
example get a lighter sensor and shine a
bright light on it or any other kind of
these kind of things so apart from the
requirements that you're testing against
um yeah like the test cases that we
described here was mainly focused uh on
UDS which is this application layer
protocol but other than that there are
these messages that are flowing between
the ccus and in the networks that we
described so what you can usually do and
what was really easy to do until a
couple of years ago was that you could
easily inject messages inside so and as
you said you can basically trick the
vehicle on for example if you have a
lighter sensor and the adaptive cruise
control is uh like focusing all the
actions all the breaking actions the
steering actions on this slider sensor
and you manage to inject messages then
you can trick it into doing some action
and that's partially what happened in
the video with uh the blinking light um
now there are several technologies that
are used like SE C to like handle the
two entities and the authentication
between the two and which ECU
communicates with wit to avoid these
attacks but it's still not obsolete you
you can still do it I'm sure that in
many vehicles you can still do it and
you can inject messages and
yeah you're welcome thank
you and okay so one last
question uh just quick question did you
look into the diagnostic test from the
OEM as an actual attack surface of like
the security access algorithms usually
having to be there for the workshop to
do service you mean which are the
security access algorithms if they are
secure so now the the diagnostic tester
usually has to have the algorithm
somewhere on the diagnostic tester which
makes this an attack surface for the
vehicle which is not actually in theide
the vehicle but on a computer in a
workshop yeah yeah yeah like usually
these testers are only going to
certified um service points so we cannot
obtain them usually we evaluate the
security access algorithms which is
something that um it can be weak it can
be not some sometimes it's only you know
a bite addition to the key which is
really dumb and you can reverse it in
like a couple of minutes and sometimes
it's a yes that you cannot bypass uh but
for this these testers no usually they
don't come to our H it's developed by
someone else most of the times not the
OEM uh specifically and they just Supply
the cyber security requirements and they
develop it
yeah so thank you very much I have
another organizator like or or
announcements uh I've been asked to
remind you that you should bring back
your bottles that you bought to the
place where you bought them if they're
empty and you might ALS o want to bring
uh some like uh bottles that are not
belonging to anyone just pick them up
and bring them back because we have a
lot of empty crates that we waiting to
be filled to to remain to exchange them
with full ones thank you very much the
next talk will be here in 15
minutes
thanks