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/2567 Thanks!
[Music]
welcome to the milway stage for our next
talk um but first things first I hope
you all are well hydrated are drinking
enough water and because of the windy
conditions have secured your tents
safely so that they don't fly around and
end danger
people I also would like to ask you if
you took cups from the heaven kitchen
and haven't returned them yet to please
return them so that the angels can drink
their liquid Fuel and can fly still fast
and happily also as we have a lot of
guests here today which is great please
um keep the pathways here clear so that
people can leave and if people want to
leave please make way for them thank you
very
much so I'm very pleased um to announce
the talk all cops are broadcasting
obtaining the secret Tetra Primitives of
uh after decades and the Shadows um here
with me are ralter and Carlo they are
going um they are researchers who also
founded a company called midnight blue
but they are going to tell you all the
stuff way better themselves so I'm going
to fly away and give the word to you and
give Applause please to our wonderful
speakers thank
[Applause]
you thank you all right
uh welcome everyone to our talk all ops
are broadcasting obtaining the secret PR
Tetra Primitives after decades and Ma
Shadows I am very excited to finally
present this to you all after two and a
half years of Silence on a matter my
name is car Meer and these are my
colleagues V boxl and unfortunately Yos
vetel who isn't here uh together we form
midnight blue a specialist security
company from firm from the Netherlands
and uh we focus on high-end uh security
research mainly in critical
infrastructure and EMB bettered systems
um the three of us found uh
vulnerabilities from everything from car
uh immobilizers the BlackBerry Q andx
operating systems and the myair classic
ridd
cards so what's
Tetra um Tetra is a globally used radio
technology that competes with the likes
of p25 uh DMR Tetra pole it was
standardized in 1995 uh by the European
standards organization at
uh who is known for GSM 3G 4G and 53 gmr
and the likes and Tetro is used for
conventional voice communication um in
handheld radios but also data
communication including machine to
machine and the interesting thing that
is that it relies on secret proprietary
cryptography so Tetro is one of the most
popular radio Technologies used by
police all around the world um with the
exception of the US and France
uh it is used by national Regional
police forces in countries like the UK
Germany uh Scandinavia and Eastern
Europe uh but also in large parts of
South America and Asia now be aware that
these Maps uh we're showing are just the
uses we could confirm through open
source intelligence and there may be
more out
there not only the police uses Tetra it
is also used by the military and
intelligence agencies across the world
uh in different capacities
and on top of that it also it's also
used by widely in critical
infrastructure uh private security
Personnel at airports harbors and train
stations they use it for voice configur
communication but it's also deployed as
a radio link in wide area scada networks
to carry telecontrol traffic for
electrical stop stations oil gas
pipelines or Railway
signaling so while Tetra is a public
standard it's cryptography is kept
secret in the figure on the right you
can see how they describe a lot of high
level schemes uh but then The Primitives
uh whose within those schemes are
essentially black boxes whose
specifications are only available under
NDA uh which means you cannot publish uh
the details of the of any findings if
you're a
researcher
um manufacturers are also required to
protect algorithms against extraction uh
this kind of security theater however um
since any top tier adversary will
already have these specifications uh
through either their own manufacturer so
for example any major country in the
world has a TCT manufacturer on their
soil for example the US the UK China and
Russia uh or they'll simply snatch them
off a SharePoint uh from a small
manufacturer meanwhile like uh
scientific researchers or the the
security Community has to jump through
significant Hoops in order to get a look
at these uh Primitives like we had
to now tet security mainly consists of
two components both of which are secret
uh this is the taa1 suite uh which is
used for authentication Key Management
identity encryption and remote terminal
disabling and then there's tea Suite
which is used for voice and data
encryption over the air uh the tea Suite
consists of four algorithms divided by
use case um so tea1 and four being
readily exportable tea2 is only intended
for European police forces as uh uh
emergency services and Military and tea3
is intended for Public Safety in uh
outside of Europe European countries but
with friendly relationship with the EU U
so this means typically India Mexico
China those kind of
countries so with this in mind let's
talk about Project R uh retra that we
undertook um we know all about kof's
principle right um a crypto system
should be uh secure even uh even if the
uh the public even if if everything
about the system is known except for the
key uh so basically no security through
obscurity uh violating this principle
doesn't usually end well and there's
plenty of examples of secret proprietary
cryptography in GSM gmr GPRS deck and
various RFID systems uh and all of them
turned to be turned out to be flawed uh
or intentionally back doored uh so why
would Tetra be
different uh now Etsy has a different
opinion on this uh in an interview with
Kim zeter the the Etsy Tetra chairman
explicitly said that they consider
obscurity as also a way of maintaining
security right so we obviously disagree
with such a uh with such an approach so
we went to the Nelnet foundation for uh
fund for um a research proposal and they
decided to fund us to open up Tetra for
public review um Nelnet is a nonprofit
organization which funds open source
projects and research like this with the
goal of promoting Open Standards so if
you have something that you would like
to investigate which Cost U significant
amounts of time I would highly recommend
approaching
them so let's break over open a radio so
uh we had to start out by picking the
right kind of radio uh there's lots of
vendor models architectures involved and
picking the wrong one can make you waste
a ton of
time uh so we went quite we spent quite
some time uh pouring over manuals data
sheets in order to get an idea of the
different architectures involved and
what kind of basements were actually
used by which fendors and uh what
architectures they were based on and if
they were any as6 or fpgas that likely
implemented the algorithms and so on and
so forth so thus we ended up with the
freon base band from Motorola which is
based on a TI omap 1 l38 s so and it's
this thing is also used in DMR and p25
radios uh so uh therefore it's highly
unlikely that the algorithms are
implemented in hardware and also
interestingly this uh this this base
band has a trusted execution environment
so that immediately caught our attention
so it's highly suitable for implementing
the algorithm
software so this baseband is used in
Motorola MTM 5400 that's a common radio
model that you can buy for relatively
cheap online uh the baseband s SOC is
just a common TI chip so unfortunate uh
so it's unlikely that it has the Tetra
Krypto in Hardware uh and it has some
software security features uh which we
suspect make it a great candidate for
protecting uh crypto from
extraction the high level architecture
um of the radio looks like this as you
can see on the right of the slide uh
there's a control head which controls
the microphone the keyboard and so on
there's a rear connector uh for the
depot programming of the radio uh and
inside there's a basement chip which
consists of two cores there's an arm
core and there's a that's for high level
uh level stuff and there's a digital
signal process
uh that's for well processing signals
and the DSP core um has a trusted
execution environment which is where the
Mad exu probably
is so the MTM firmware format is shipped
in an rpk package uh turns out that this
is just a zip archive uh with a bunch of
uh z19 files encrypted in
it um but since the firmware files are
not personalized for an individual radio
uh there has to be a ual way to load
them and the programming software
decrypts those files in the zip archive
the zip archive is password
protected um so um it gets the files out
of them and then uses it to program the
radio so after some light net reverse
engineering we found static passwords
for these files so this is an easy
hurdle to take so now we can extract the
z90 files and decrypt them with the
password extract the s919 files which is
Motorola s record file um then parse
them identify firmware components uh
within it like the kernel or a file
system or a baseband uh uh firmware
image and so on and so forth and once we
have that let's let's look at the DSP
firmware and see what's in there because
we don't have tooling yet in order to
properly uh uh reverse engineer it we'll
just have like um um a very high level
overview of it as of now as of now and
uh well if you look at entropy analysis
uh the entropy distribution of the DSP
firmware there's a single area with
extremely high uh entropy and it's
referenced by a bunch of system calls uh
that's related to The Trusted execution
Environ API So This is highly likely
containing the secret sauce um so let's
dive
deeper so now that we have a good idea
of where to go uh how do we break the
trusted execution environment well uh we
first have to get code execution on the
application processor so that's the arm
core uh so um by the way this thing uh
has secure boot so we need we cannot
just go in and modify uh the memory
chips uh so this goes through three of
through three possibilities the first
one this thing uh the rear connector on
the back has a modem 80 command
interface um the other possibility would
to modify the the the memory and see if
we can find some some uh memory
corruption exploit through that uh or
through some peripheral interface for
example this thing talks to a GPS module
so maybe it's interesting to maybe those
links are trusted and maybe we could get
code execution through them after that
uh we'd have to hop on to the DSP so get
code execution there this might be uh
possible through direct memory access or
the DSP link Library this is a library
that passes messages back and forth
between the armc core and the DSP and
finally we had to find a vulnerability
or side channel in the te
itself so uh let's begin our
journey this is basically the last slide
but then a bit
prettier all right um so the MTM has a
rear connector that exposes the at uh
modem command interface uh here you can
read and write parameters for example
and analyzing the firmware gave us a
list of commands and we immediately
started looking for commands that handle
strings with variable lengths uh or or
some parsing
involved and there's this command that
is used to set a to group list entry and
another one that enumerates them and we
found that there's a classic format
string vulnerability in there that
allows you to write any data uh in in
some address that is already on the
stack so you can basically interpret a
value on the stack as a pointer and you
can write to that to that address uh now
if we control a value on the stack that
that would mean we could write anything
anywhere unfortunately we
don't so luckily there is frame pointers
uh in this firmware uh so frame pointers
have the nice property that one frame
pointer points to the next and due to
the the circumstances that we have here
uh we can only write a single bite uh to
an address that is on the stack so what
we do is like we have three frame frame
pointers here one point to the other
which points to the next so the first
one uh we write a single bite to the
next and therefore we use we can um we
can change the least significant bite of
that address where that pointer points
to so therefore we can use it as a
cursor to write over the next address
and therefore we control the full
address so now we have a write anything
anywhere
primitive so now that we have that uh we
can use this fact that you can use we
can use the fact that the read uh
somehow has read WR execute permissions
uh so we can just straightforwardly
write the Shell Code onto the Heap uh
then override some pointer to executable
code trigger that pointer execution and
boom we have a shell code we have we
have a root shell on the arm core
right thank you all right the next step
would be to move move onto the DSP uh so
to recap that would be exploiting
vulnerability in DSP link the message
passing framework or uh exploit some
flaw and misconfiguration in the the
firewalls let's say between the arm core
and the
DSP uh so the two cores within the Bas
band need to communicate uh they do this
by having shared internal RAM and some
external DDR memory and this could
present an interesting Avenue for
lateral movement towards the DSP
so the S so in question has memory
protection features which allow for the
segmentation of memory errors between
cores and within
cores So the plan would be to dump the
mpu configuration then find ranges used
by both the DSP and the application
processor and then identify and exploit
an interface that uses uh these memory
ranges such as DP link uh that is used
to uh to have these cores talk to each
other um however when we dumped the
configuration uh we saw that essentially
no segmentation was applied whatsoever
uh so these mpus POS zero problems and
made our life a lot easier so this
basically means that getting code
execution on a DSP is a straightforward
as like loading a curle module asking
for a buffer that uh that maps to this
physical address that's supposed to be
uh DSP memory and just override parts of
the DSP
firmware
are we okay yeah
okay um so now that we have code
execution on DSP we implemented a
framework for running code on it uh we
wrote multiple uh application processor
kernel modules which hijack DSP control
by allocating a shared buffer uh copying
our payload into it and then redirect
DSP execution to that and meanwhile we
made sure that there's this Hardware
peripheral called a watchdog and it
needs to be set IFI every now and then
otherwi it spontaneously reboots the
board uh so we got that on control as
well uh all of this was kind of
complicated by the fact that the DSP
architecture is py hellish um it has
delayed branches variable de degrees of
concurrency uh lots of uh conditionals
and no support for Ida uh so we had to
implement our own disassembler and on
top of that we also ported the
architecture to the red deck decompiler
so this is the disassembly output and
this is the decompiler output um so you
can read as you can see this reads a lot
easier than the dis
assembly good all right and with that we
had reliable DSP code
execution
[Applause]
right thanks so that brings us to the
last part of this reverse engineering uh
process we now have to somehow break the
DSP trusted execution environment and in
order to explain that to you let's first
dive into how this thing actually works
so the chip is a Texas Instruments chip
with a ROM code in it and in this ROM
code is embedded what they call a secure
kernel and this is like a a lightweight
library or operating system kind of
thing that runs in a secure mode so most
code running on the DSP runs in insecure
mode and can use the secure kernel but
cannot see it and cannot interfere with
anything that happens within this pret
execution environment or or other secure
context stuff so what non-secure code
can do is use uh functions like SK load
and SK load is a secure kernel call that
allows for the runtime loading of an
encrypted module and this module is then
uh copi to the secure context it is
decrypted using uh a factory set key the
customer encryption key it is then
validated using RSA and if everything
checks out it remains present within
this protected context and it can be
used by non-secure code through the use
of the SK SK algo invoke function so it
can then uses use the algorithms but it
cannot see
them um yeah so let's dive into car cach
architecture because we're going to use
this in our
attack the omap l138 uses a two two tier
cache architecture it has a level one
program and data cache and it has a
level two cache and if the CPU performs
a memory lookup uh it will first check
whether the data it wants to uh retrieve
is already present in one of these
caches and if so the read request is
serviced very quickly if not it has to
take a detour or actually the full route
all the way to the um the memory chip
ddr2 chip which takes significantly
longer now as we are running non-secure
supervisor level code we can manipulate
some of the cache mechanics what we can
do is evict uh lines from the cache so
we can say okay this address if it is in
Cache I would like to throw it out of
the cache and what we also can do is
freeze the cache this is a A peculiar
function that I haven't seen before in
other chips but it allows you to switch
the entire cache to a readon mode so it
will be used to accelerate a lookout up
if uh something is present but the cach
will not be
updated now we can use this um some of
you may be familiar with the structure
of AES but if you don't the first few
steps are listed listed here I wonder
who is able to read it but the slides
will be online or some of them are
already online uh so you can Al always
look look back if you need to in any
case the first thing that happens during
a decryption is that the round key an
AES key is sord into the AES state so a
CER text goes in a round key is sored
through it and then further steps are
taken and one of the later steps is um
inverse sub bites which performs a Lup
in a table and this table is called
called the sbox it's a 256 byte table so
a state byte is used as an index in this
table and whichever is there is then the
new value for that
state so we do not know where this box
resides it's somewhere in this Texas
instrument ROM code but we cannot read
all of it so we somehow have to figure
out where where the sbox lives and we do
that by um throwing out a small part of
the uh secret ROM code from the cache
using our eviction control and then
measure how long it takes to perform uh
a module load so we try to load a module
and we see how long this uh this takes
on average and then we throw out another
part of the uh secret page and we check
how long that takes to load and what we
get is uh a plot something like this
most addresses do not affect the running
time except a small portion where a
drastic performance penalty is seen if
we throw that out of the caches so
clearly these are the areas that uh uh
that the sbox
resides so fully blindly we we managed
to to locate the sbox in in Rome and for
the remainder we will uh assume the
following setup we ensure the entire
table the entire sbox is loaded Into
Cash memory by loading a module once
then we use our eviction control to
throw out the first 32 entries and then
we enable cash free so what we have now
is a situation where a look up in the
first part of the sbox which we call the
first octant will incur a performance
penalty that we can see and a lookup in
any other part of the sbox will be
serviced quickly from cache and will not
show the the penalty and this setup is
assumed for the remainder of this uh
section so the attack will work as
follows we set our first cfer text bite
to zero and we randomize all the other
cfer text bytes and then we ask the
secure kernel to load this module it
will try to load it of course it will
fail validation so it will reject the
module but it will it will decrypt it
first so we can see whether um if we set
the CER text by to zero whether it
incurs this penalty or not so in short
you have this AES State bite it goes as
an index into the table if it hits the
first part it will be slow if it hits
the rest it will be fast and uh we do
that repeatedly for all values for c for
the first CER text bite and if we plot
that we see this for those who do not
see it I shall describe it
the first 32 entries are uh are fast
then we get 32 entries that are
significantly slower and the remainder
is fast again so what we have here is
that the first cerx bite sort with the
first round key bite is uh is exhibiting
a performance penalty when it is between
32 and 64 so we have effectively
recovered three bites three bits of this
bite so we can repeat that for all the
other bytes and we can get 48 bits of a
round key which is amazing but not
enough because 80 bytes 80 bits remain
and that's just too much to Brute Force
at least for someone with our
equipment um so we somehow have to go
deeper why doesn't this work this
doesn't work because the least
significant bits of our cfer text and of
the round key bite do not influence in
which octant the lcup will hit so this
is inherently
limited and as such what we decided to
do is take the attack one round further
we will not Target the sbox Lup in the
first decryption round but in another in
the second decryption round to make sure
that the least significant bits are now
indeed affecting the most significant
three Bits And as as such are affecting
in which octant the uh the the lookup
occurs now it's complicated because you
have to account for some stuffff there
is some row shifting around uh there is
another round key bite that is uh uh
affecting the state and also there is
this uh mix columns step that U performs
a computation over multiple State bites
so this gets all mixed up we were able
to account for all of that I'm not going
into detail for the sake of time um but
we managed to get it working and I'll
now show a short demo
video
so what we see here is how we load some
kernel modules on the application
processor um I cannot read it myself but
oh yeah I can clearly here we are
loading a module that kicks the Watchdog
so we hijack the execution of the DSP
but the Watchdog has to be serviced in
order to prevent a board reset and then
we start uh Gathering uh measurements
from the
DSP the uh uh yeah we're collecting
collecting timing data and constantly
comparing the timing data to a profile
we built and we can recover uh bytes of
round key 10 in this
way uh this takes about a minute and
then it will have recovered all of the
16 round key btes if you have all round
key btes you can reverse the the key
schedule AES uses and retrieve the
original base
key
all right so there we have it
thank
you cool so without a within about a
minute we
recovered the uh the cryptographic key
from this radio fully running on the
radio by the way what you saw was not
the actual Motorola key we changed it
because if not people would get really
angry at
us we're good we're
good okay um so now that we were able to
decrypt our module there was some other
Hoops to jump through but I'm going to
skip that in the interest of time we
were able to decrypt the module that
embeds the Tetra cryptographic
Primitives recapping we first attacked
the at modem command interface we found
the format string vulnerability which we
exploited we pivoted to the DSP through
unconfigured memory protection and we
then performed a cache uh timing side
Channel attack on The Trusted execution
environment so let's briefly discuss
some of the findings uh on The detet
Primitives we found uh the taa1 suite we
recovered it we reverse engineered it
and what's interesting is that we found
that all Primitives that in the standard
are called called ta something are based
on a proprietary proprietary hurdle
block CER and all the TB Primitives are
just simple sores or some additions or
really really lightweight stuff and also
interesting is that we found that some
uh blocks are identical or highly
related for instance da1 equals da41 and
we used uh our new found knowledge on
these Primitives to construct some
attacks one is that we can under some
circumstances pin a session key to zero
and another one is a deanonymization
attack that allows you to decrypt the
identities that are uh using a Tetra
Network now the actual encryption on a
tetron network is done by one of the
four keystream generators that Carlo
just pointed out and what you see here
is a schematic overview of ta2 you see
the key register on the top 80 bits and
you see the state Register at the bottom
that gets some influence from the key
register to us it looks robust but
forther further scrutiny is needed in
order to uh to be able to publicly
determine that this is fit for purpose
what's definitely not fit for purpose is
tea1
which shares the same structure but the
first thing it does is execute a a
secret key compression step the 80 bit
key is compressed to 32 bits and only
then it starts generating keyst stream
based on those 32 bits of
entropy so uh this is obviously trivial
to attack it takes about a minute on uh
on my graphics card which is a uh 2016
GTX 1080 and in the interview Carlo
referred to previously with the Etsy uh
chair that he he made some statements on
that an attacker would need a high
powerered graphic graphics card I I I'm
not sure um and that 25 years ago this
could have been sufficient maybe maybe H
32 bits was different different back
then than now computational advances
blah blah blah but still that you would
need some pretty reasonable equipment
now I don't think I have to explain to
any of you that this is just not true
but instead of arguing uh why not just
throw overboard all these assumptions
and reasonable uh ideas and just see
what this bad boy can
do hi we're midnight blue about two
weeks ago we announced the Tetra burst
vulnerabilities consisting of five
vulnerabilities in the Tetra radio
standard two of which are deemed
critical since then Etsy the
standardization body responsible for
Tetra has made public statements in
which they downplay the seriousness of
the
vulnerabilities in these statements they
resorted to a semantic discussion not
calling a spade a spade or more
specifically not calling a backd door a
back door furthermore they made a number
of evidently false statements such as
claiming packet injection and ta1
encrypted networks would be impossible
and that 32 bits of cryptographic
strength would have been sufficient in
the late '90s to any information
security expert it's pretty clear that
this is not the case but to help remove
those few remaining doubts we decided to
take on the challenge of cracking tea1
on this beautiful machine produced in
1998 running good old Windows
[Music]
95 frankly the hardware is so old that
it wasn't easy to get our hands
on when we run the cracking tool we see
it reports that it need needs about 13
hours to go through the entire search
space after 12 and 1/2 hours the key is
found demonstrating the feasibility of
cracking ta1 on '90s consumer
Hardware all right Etsy now that we've
cleared up this issue please let us know
if you'd like us to demonstrate pcket
injection as
well right so I think we got that out of
the way um now you might think okay this
is ta1 it's back doors how about the
other ones they're still safe right ta2
used by European law enforcement and uh
other uh parties um should still be
robust because the algorithm seems
robust well not necessarily because we
found a protocol level flaw
um it in in short it it goes like this
these keystream generators they
obviously take a key but they also take
an IV to make sure that every key stream
differs from previous keyst streams and
this IV is constructed from the network
time so the uh the frame counters
multiframe counters and Slot counters
that increment through time are used in
the generation of a keyst stream and how
does the radio know what time it is what
network time it is well it knows because
the infrastructure tells it uh there is
this sync frame and CIS info frame that
together specify the network time time
and these frames are broadcast in an
unencrypted fashion without any kind of
uh Integrity uh guarantee whatsoever or
cryptographic Integrity in any case and
also just regular singaling messages
also do not really carry any
cryptographic authenticity guarantees an
attacker can just flip bits and it will
be interpreted as at face value after
decryption you can do whatever you want
the radio will decrypt and try to make
sense of it so the outline of the the
attack very briefly would be as follows
um imagine that we uh overpower uh let
me start again sorry you put me off um
so let's let's say we have captured uh
an encrypted message at some time T we
then uh can Target a Mobile station at a
later point in time it may be the same
radio may also be another radio that has
the same uh key material and we use a
directional antenna or just proximity in
order to over power the infrastructure
signal and we have then impersonated the
uh the infrastructure towards that radio
and what we can do is then tamper with
these sync and CIS info frames to put
the radio in the the time that was uh
applicable at at the moment we captured
this message at time T so we put the
radio back in time and then it will
start reusing these RVs reusing this
keystream we then pull some tricks which
are uh involved and I will not explain
now we pull some tricks in order to uh
understand what keystream is being used
at that time we recover the keystream
and we can then decrypt the message that
we have previously
captured so when we told this to Etsy uh
at a quite early stage of our disclosure
process they said okay this is a valid
theoretical
attack they didn't think it was really
feasible in practice and we were like
yeah but this is really serious uh maybe
you can provide us with a base station
and we can instrument it and in that in
that way we can all know whether this is
a big problem or not so much so they
said l no the word the wording was
probably different um some other
stakeholders also responded like this so
we had to look for Alternatives and what
we did is uh well the the following we
got ourselves a base station so meet our
mbts it's old it weighs 75 kilos uh it's
clear text so it didn't support
encryption and it's cool as [ __ ] we
instrumented it we added encryption
support we added uh a module loading
system that we could add our own uh
console commands to it to implement the
proof concept of uh of our attack which
I will now briefly
demonstrate hi we are midnight blue we
have uncovered several serious
vulnerabilities in the Tetra radio
standard D Tetra burst we will first
demonstrate a decryption Oracle attack
to recover a text message but the attack
can also be applied to voice
communication and data the demonstration
takes place on our lab
setup the radio receives an encrypted
message which is also captured by the
attacker we see the message says
secret the attacker now needs to Target
a radio and impersonate the
infrastructure and carry out the attack
to decrypt the previously captured
message
we have sped up this
process the attacker has now recovered
all he needs to decrypt the message this
attack applies to all tatra
configurations but can be resolved with
a firmware update further details will
be disclosed on August
9th
thank
you so it's not a real time attack but
it definitely allows you to to decry
previously captured
traffic also since we were instrumenting
this base station we found some issues
there uh it it accepts unauthenticated
firmwares which are stored on the side
controller inside this thing uh which
was highly convenient to us but maybe
not such a good idea for a piece of
equipment running critical
Communications
um it has hardcoded backdoor passwords
uh embedded in the firmware as far as we
know they're undocumented uh they
provide you an authentication level
beyond the level that the legitimate
owner of the system would
have and lastly if you manage to crash
the side controller through some kind of
unhandled exception it will drop to a
debug prompt offering you raw memory
access and code execution um which which
allows for for key exfiltration and yeah
everything basically uh so given the
radio given the Mobile station given
some other experiences that we've had
there seems to be a a a larger problem
here um Tetra equipment is not really up
to speed when you compare it to
something like an Android phone and
actually we start wondering whether
anyone is taking a look at this at all
from a security testing
perspective so briefly on the
coordinated vulnerability disclosure
process we started working on this in
January 2021
and it took us four months to get the
cryptography out of our MTM radio uh in
December that year we contacted the
Dutch ncsc which then helped us uh relay
our uh findings to uh many different
stakeholders uh in January 2022 we had
meetings with the Dutch police with Etsy
the standardization body uh we had
meetings with the intelligence agencies
to uh to discuss the the Imp impact of
these things and we distributed a
preliminary advisory more oriented
towards stakeholders about what they
should probably be doing um we spent a
year and a half in this coordinated
disclosure project uh process and uh now
we're finally here able to talk about
this to all of
you something about mitigations the
keystream recovery attack can be
resolved with firmware updates it is
important that you check whether these
firmware updates actually address the
issue because it's quite a tricky thing
to get right uh alternatively end to
endend could help or if you're using
Tetra in a data carrying capacity TLS or
ipsc tunnels may help to add another
layer of encryption on top of tetra the
T1 back door cannot be resolved through
a firmer update because it's in the
standard so you would need to switch to
ta2 or if you cannot do that maybe ta3
or end to
end uh the deanonymization attack is not
fixable as well because it's also part
of the standard you'll have to wait for
uh the new version of the Tetra standard
to to hit the markets which embeds a
suite called ta2 with a new identity
encryption primitive and finally the
session key pinning attack uh can also
be resolved in
firmare so in conclusion uh we have
presented the first public in-depth
security analysis of Tetris since its uh
Inception uh over 20 years over 25 years
I'd say actually uh we reverse
engineered the secret cryptography out
it made it public for all of you to see
it's on GitHub we uncovered multiple
vulnerabilities including a back door in
uh an algorithm that's broadly used in
critical
infrastructure uh the implications for
uh for these systems are uh are quite
immense patches are available for some
mitigations for others and the new
standard addresses some of these these
things but the new standard uh
introduces also New cryptographic
Primitives which are again held secret
so uh yeah I'm not sure if I would
recommend that actually I am
sure so in uh that was that uh I'll
gladly take any questions if there's
still some time
[Applause]
left so so thank you thank you thank you
thank
you thank you thank
you I get a new
microphone thank you yes so thank you w
and Carlos for your um great uh talk um
so are there any questions from The
Ether signal Angel zero great so um here
is uh the angel with the microphone so
you can go to him to ask your question
questions one quick question so there is
no public key it's onlyc ke it's also
symmetric keys can you please repeat the
question because the internet cannot
hear it uh this man asked whether there
is any public key cryptography and no uh
Tetra is fully based on symmetric
Keys uh my questions are mostly
geopolitical rather than uh um technical
though there's one technical followup to
that which is our is is there any
evidence that the symmetric keys are
partitioned according to alliances or GE
or political boundaries for example
would Russian uh police have a different
uh access to a different symmetric key
than some of the others so uh it's it's
not really a matter of access to keys
but it isn't a matter of access to
algorithms what you see is that tea2 was
designed for uh emergency services
within Europe and tea3 was intended for
uh Emergency Services outside of Europe
that we had good standing with and uh
probably
interesting to you is that te1 was also
given to emergency services that were
less of allies to the European Union so
in Eastern Europe in the balcon
countries you see police and military
forces relying on a back door algorithm
because at that time we were not best
buddies uh maybe we are now but yeah
these these networks are there now
changing the algorithm is really hard so
we're stuck with this problem for a
while
so let me interject also on top of that
um for example if you're a private party
like a harbor or or an airport or
critical infrastructure you're not a
police force so you're stuck with ta1 or
no encryption at all that's basically
the two options that you have yeah yeah
excellent addition yes so please uh we
don't have much time so for one more
question please give it to another
person and contact for other person
afterwards thank you hello um I have a
question you kind of hinted at that a
different handset can have the same keys
so would that make the key uh key stream
extraction possible real time that uh
someone is intercepting uh uh encrypted
stream while someone else with the
same key Hing handset runs your attack
in real time for example would that be
possible yeah so yeah most keys are
network wide like uh Group keys for talk
groups and stuff they're Network wide so
the thing with the key stream recovery
is that it just recovers one bit at a
time so it is slower uh uh with a factor
of the time of the transmission but what
you could theoretically do is Target a
100 Mobile station in remote places and
in that way get much quicker recovery of
key if you would really want to but yeah
if doesn't answer
perfect is it a short question yes okay
short answer and then sadly we have to
go but you can of course always contact
them for more questions so with your
nice Mobile station you hacked now can
we have now additional to deck also
Tetra at the
Poke if someone is willing to put the
effort
in by by the way way um we got ours from
eBay and there's there's there's still
two that you can
buy
10,000 there's one for 5K available but
it has few I think a further um
discussions on this can be had on the
side of the tent um thank you again so
much for your
[Applause]
talk
[Music]