all right hello and welcome everybody to our talk tetra tour de force jailbreaking digital
radios and base stations for fun and secrets I'm very excited to stand here today and share
this research with you after working on it for more than two years my name is Jos Wetzels and
these are my colleagues Carla Meyer and Wouter Boxlack and together we form Midnight Blue a
specialist security consultant for consultancy firm that specializes mainly in embedded systems
as well as critical infrastructure so a little bit about tetra what is tetra it's a globally
used radio technology that competes with the likes of p25 which you might know from being
used by the United States police DMR and the confusingly named tetra pole and was standardized
in 1995 by Etsy that's the European telecommunications standards Institute and they
are known for also doing work on GSM 3g 4g and so on it's used for voice and data communications
as well as
machine-to-machine communications and it relies on secret proprietary cryptography that's why
we're standing here today so it's the vast majority of global police forces outside of
the United States and France use tetra for their voice communications and this is countries like
the Netherlands and Germany and the United Kingdom but also Scandinavian countries Eastern
Europe large parts of Asia and South America use this in addition it's used in military and
armed services contexts now the countries that you see highlighted on the map here are the ones
where we could confirm military or intelligence users through open source intelligence but this
is likely the tip of the iceberg so there might be many more countries out there that use it in
this capacity and on top of that it's used by critical infrastructure so if you see private
security forces at airports harbors and train stations there's a good chance that their
handheld radios are tetra based and on top of that it's also used as a
link for wide area networks carrying SCADA communications in order to do
telecontrol and telemetry of high voltage substations oil and gas
pipelines as well as railway signaling so serious stuff now a common
misconception is that tetra is an open standard but that's not true some parts
of the standard are public but the cryptography within it is secret and
it's only available to you if you sign an NDA and I mean in that case you can
talk about it and you're only allowed to sign an NDA if you are what they
call a bona fide party and these bona fide parties are usually manufacturers
and these manufacturers have to ensure that the algorithms are protected either
by implementing them in hardware or implementing them in software with
extraction countermeasures now the first problem already is that there are lots
of these bona fide vendors and they are geographically dispersed so every major
country in the world essentially has a domestic tetra manufacturer that's the
United States the United Kingdom China Russia so you can feel that top-tier
adversaries are going to have a lot of problems and they're going to have to
like likely already have these specifications of these algorithms
either through their in-country manufacturers or to just you know
getting them from a SharePoint somewhere and a manufacturer we however
had to jump through a lot more hoops in this case so tetra security has two main
pillars the first of which is the TAA1 suite which is the authentication key
management and distribution suite it's also used for identity encryption the
second suite is the tetra encryption algorithm suite which is used for voice
and data encryption through the
interface encryption functionality and this has four different flavors the
first of which is ta1 which is readily exportable then you have ta2 which is
restricted in its use to European public safety organizations then you have ta3
which is used for extra European public safety for those countries that are
friendly relationships with the European Union and then you have ta4 which is the
same use cases ta1 but it's hardly used practice optionally there are tetra
end-to-end solutions available but these are only used by some countries
and only in special cases in most of the cases so think about special
intervention units counterintelligence observation units it's not a part of the
tetra standard there are some guidelines around it but it's a vendor specific
proprietary solution that you bold on top of the air interface encryption it's
expensive and again very opaque as well hasn't been looked into yet so with this
in mind we undertook project re-tetra which was the project to reverse
engineer these
these these these algorithms and you can find all the details about this on
this particular URL we undertook this with Kirchhoff's principle in mind now I
probably don't have to explain to you guys what Kirchhoff's principle is but
I'm still going to anyway it says that a crypto system should be secure even if
everything about the system except for the key is public knowledge so no
security true obscurity right violators of this principle have historically not
done well if you look at the history of standards like GSM GMR GPI
RS all Etsy standards by the way there are secret cryptographic algorithms either
turned out to be broken or backdoor and we had the suspicion that this might be
the case for tetra as well but in more than 20 years nobody had looked at this
publicly now Etsy thinks very differently about this in an interview
with the journalist Kim Zetter Brian Murgatroyd who's the chairman of the
Etsy technical committee on tetra said well obscurity is also a way of
maintaining security well let's see if that's actually the case so the the
project was undertaken with funding from NL net which is a Dutch nonprofit
organization that hands out money for open source initiatives and they kindly
supply this with some money to undertake this research and now we can
talk about tetra for the first time in public so let's break open a radio well
before we could break open a radio and see what's going on inside we did a
little bit of analysis first because you want to select the right kind of target
because if you select a radio that is harder to reverse engineer you might end
up spending a lot of time on that
end so we did some analysis of the internal architectures of different kind
of radios from different vendors by looking through the different data
sheets and here you can see that well there's a variety of architectures some
of which are quite esoteric but also they implement different kind of
security features like certain radios will implement hardware based ASICs that
likely include the algorithms and we don't want to spend a lot of time with
assets and scanning electron microscope microscopes so we went for the one that
has a trusted execution environment in
software and that turned out to be the Motorola MTM 5400 this is a very common
model it's easily obtained secondhand online on eBay and it has a baseband
system on chip that is by a manufacturer that is not Motorola but
by Texas Instruments and is likely hints at the fact that there's no
hardware implementation of these algorithms inside also this SOC has
software security features and that are very suited for likely protecting this
tetra crypto from extraction now the architecture of the radio
looks like something you see on the right of the slide so if you have the
radio you have a control head which is where the microphone the keyboard and the
field configuration is then on the back of the radio you have a rear connector
which you use for Depot programming for configuring the radio doing firmer
updates and so on and then inside you have the basement chip and the basement
chip in this case the Freon baseband is based on the omap l138 architecture by
Texas Instruments which has a arm core for the high level stuff and a digital
processor for well processing the signals and then inside the DSP you have
a trusted execution environment that likely includes our magic sauce
so this all map l138 like I mentioned it has an arm core but it also has a
DSP core that is based on a flavor of the TMS 320 DSP architecture there's very
limited reversing tooling available for this particular flavor so we had to build
a lot of our own and the DSP features an orthogonal security model so you have a
separation between the regular user and supervisor mode but you also have a separation between
secure and non-secure mode and if you look at the supervisor secure mode that is likely where a lot
of the interesting stuff is located first thing we did is we bought a development kit for this
architecture was relatively low cost unfortunately this didn't come with the secure version of the
chip so we couldn't analyze it on a development board however it's useful for reversing debugging
testing your shell code and so on
so we wanted to confirm our assumptions so we opened up the radio and we saw that all the
main board was covered with shields so in order to see you know what kind of chip is exactly used we
took a rotary saw we saw it of these these these shields and we found out that yes it is indeed this
particular chip with the secure flavor then we took a look at the firmware the firmware comes as
an rpk package and the rpk package well it's essentially a zip archive and inside the zip
so you know these firmwares are not personalized they don't differ from radio to radio they're
general and the engineering software needs to have a way to load this firmware onto these radios so
likely it knows the passwords to these encrypted files it's written in dotnet so it's very easy
reverse engineering with a little bit of effort you get the two passwords which are static
so then you're able to extract the zip archive you get the z19 file you decrypt it with one password
then you get the s19 files you decrypt those with the second password
and then you have what you're actually looking for which is the file system of the application
processor and the DSP firmware so is this trusted execution environment actually used for the tetra
algorithm algorithms well there's no proper DSP reversing tooling yet so how do we find this out
we'll be doing the entropic analysis of the DSP firmware so you can see on the left of the slide
that in a particular area within the DSP firmware there's a very high entropy area which likely
indicates encrypted data and then you can see the cross references in the code to this particular
area correspond with API call invocations of this particular secure kernel API so delving into a
little bit more detail will be my colleague Carlo Meyer who will take you on the rest of the journey
all right um so now that we have a pretty good idea of where to go and let's break a TEE
and so the first thing we have to do is get code execution
obviously on the application processor and we identified three possible angles
um the first one being the modem 80 command interface the second being modifying the NAND flash
and the third one being targeting some peripheral interface for example like the GPS module or the
what have you after that we'd have to move from the arm core towards the DSP through either direct
memory access or through some
relink library which is the library used to pass messages back and forth from the arm core to the
DSP and vice versa and finally once we obtain code execution on the DSP we'd have to find either a
vulnerability or a side channel flaw in the trusted execution environment so this is basically the
same thing but then presented in a nicer way okay um so the MGM radio has a rear connector that
exposes the 80 modem command interface
um with this interface you can read write parameters for example
um analyzing the firmware gave us a list of commands and we immediately started
looking for those with string parsing or variable length handling
um the commands used to set a tall group list entry and subsequently enumerate them we found a
classic format string vulnerability which allows us to write
arbitrary data to any pointer that's uh that's listed on the stack and so on the slide on the
right you see our user input that contains percent P and on the bottom you see it interpreted as in
format string so this is a classic vulnerability um so this means that if like we can write
anything that we'd like to anything that's listed onto the stack so if we can influence
what's on the stack we have a write anything anywhere primitive unfortunately we don't
have a write anything anywhere primitive so how do we go about that so there's uh luckily there's
frame pointers in this firmware um frame pointers have the nice property that each frame pointer
points to the next frame pointer so in this particular example let's say that argument 55
uh that one contains a memory address and it's it points to argument 59 which in turn points to
argument 71. now suppose that you write let's say zero x 80 to argument 50.9 which in turn points to argument 71.
that will update argument 59, and in this particular example, it will now not point
to argument 79, but it will point to byte zero of argument, not point to argument 71,
but in this particular example, it will point to the byte zero of argument 79.
All right, so now if we write anything to argument 59, it will update byte zero of argument
79. Then we go back, and we update, then we write something to argument 55 again, for
example, 0x81, and therefore argument 59 now points to byte one of argument 79, and this
way, by continuing this route, we end up being argument number 79 being completely malleable
by us. We completely control its value, and this way, we have a pointer on the stack,
that we completely control, and therefore, we have a write anything anywhere primitive.
Good. So, it turns out that the heap actually has read, write, and execute permissions,
so the next steps would be just to write our shell code onto the heap, overwrite some pointer
that points to executable code, and then trigger execution of that pointer, and boom.
So, that got us a shell on the application processor.
All right. So, the next step is to move on to the DSP. So, to recap, this means
exploiting vulnerability in this communication library, called DSP link, or exploit some
misconfiguration in the MPU's configuration. Right. So, this thing contains two cores
that need to communicate somehow, and they do this by having shared internal RAM, and,
some external DDR2 memory. And this could present an interesting avenue for lateral
movement via direct memory access. So,
exploit an interface that uses this shared memory range such as DSP link
that's used in order to pass messages back and forth so when we dumped the
configuration we saw that there is essentially no segmentation applied
whatsoever so basically this this MPU poses zero problems for us like getting
code execution on the DSP is as straightforward as just modifying parts
of the DSP firmware in RAM so the next thing we did is we implemented a
framework for running code on the DSP we wrote multiple application processor
kernel modules which hijacks DSP control by allocating shared memory copying our
payload over into the shared memory and then redirect DSP execution to our code
and meanwhile ensuring that the watchdog which is a hardware peripheral was
periodically kicked in order to prevent the board from resetting so all of this
was kind of complicated by the fact that the DSP architecture is pretty hellish
it has delayed branch branches variable degrees of concurrences lots of
conditionals and very limited IDA support so we had to implement our own
disassembler and on top of that we also added support for the architecture to
the red deck decompiler and both will be upstreamed in the in the course of the
next few years.
As you can see the decompiler output reads a lot nicer than the disassembler
alright and with that we had reliable DSP code execution so on to the final
step attacking the TEE so at first we got our hands on a chip whisperer
to do some power side-channel analysis however it quickly turned out that it
wasn't the easiest route at all we had to find clock lines on the PCB we then
find then find the DSP power line and decrease the DSP core clock speed
correlate measurements to the key etc etc which turned out to be a nightmare
we were quite sure that we are going to break the board this way so we took a step back and we looked at maybe we could attempt to fix it.
we have other options here so it turns out the T is implemented in ROM by a
subsystem called the secure kernel this codes runs DSP runs in DSP secure mode
and all non secure mode code code can do is a perform a secure kernel API call
which is very similar to a syscall on a regular PC so there's this thing called
SK load which is an API call which allows for runtime loading of encrypted
modules for example our tetra module which contains the tetra algorithms and
it then decrypts these more this module with AES and validates them using RSA
and then loads them into the trusted execution environment where they're
invisible in non secure mode then if you're back into non secure mode you can
invoke one of these algorithms through SK algo invoke and which
uh
allows non secure code to invoke these algorithms and get the result from one
of these functions that was previously loaded and these modules are encrypted
with a customer encryption key so that's the factory set key in this case that
key belongs to Motorola so now for our tech we got some inspiration modern
computers use caches to speed up memory accesses and this introduces some
timing differences during lookups
uh and this in turn may leak some information on secrets involved so in
2005 already uh Daniel Bernstein wrote an interesting paper on performing such
attacks on AES where you build a profile of timing differences and then you observe
the target's system characteristics you correlate these with the observation and
then you derive which key fits best right so for the DSP we are targeting it has several caches you
have a data cache you have a level one code cache and you have a level two cache the level one data
cache has a 64-byte line where memory reads are fast and data that is already for data that's
already cached and otherwise it's slow so we can evict addresses from cache in this 64-byte
granularity and it turns out that doing so from uh from non-secure mode also affects secure portions
from the uh address space so that's why it's so important for us to be able to do this in the future
database that you cannot usually read from non-secure mode um furthermore there's a feature
called a cache freeze which basically means the cache is turned into read-only state uh which
means that whenever you get a cache hit you get a performance increase whenever you get a cache miss
you have to fetch it from main memory but the cache isn't updated so now that we have some
control over the cache uh which AES decryption decryption step should we do in order to be able to
retarget well it turns out that inverse subbytes we're decrypting AES so inverse subbytes uses an
s-box and that means a memory lookup so we should probably target that the thing is this s-box is
located in some page in ROM but it's not readable from non-secure mode so we don't really know where
the s-box is so first thing we have to figure out is figure out where the s-box is so what we did
is we start by evicting the first cache line
the first 64 bytes of this ROM invoke skload and then measured the time it took to to run that code
in terms of clock cycles and then we do so for the second cache line and then the next and so forth
and eventually we plot this so we get something like this so it seems quite obvious the s-box is
right over there okay so let's look a bit deeper um we're going to prepare the cache
follows we run skload so that the full s-box will be in cache and then we evict the first 32 entries
so this is what we refer to as the first octant because it's one eighth of the s-box and then we
enable this cache freeze feature and now whenever a timing penalty occurs we know that this happens
due to the first octant of the s-box being hit so we'll assume this setup for the remainder of the
presentation so having evicted the first octant of the s-box from cache we set ct0 so that's the
first ciphertext byte that we provide to skload we set it to zero and we randomize the remainder
of the ciphertext and we get and we measure average running times of skload and then we
repeat that for all the values of ct0 as well and then we plot the results so again we set the first
ciphertext byte to zero we randomize the remainder and we get the average running time
of skload and so that thing now our controlled value gets put through the s-box
so when we plot that we get something like this which is quite interesting so we know for by
construction that the penalty is observed when our ciphertext byte x or a round key byte is less
and in the above example we find that this leaks some information about the round key byte so in
this particular case the round key byte is located somewhere between 32 and 64. so that's great we
effectively leaked three bits of this round key byte so we repeat the same thing for all the uh
for the remaining remaining 15 round key bytes we obtain a total of 48 bits of round key
however this approach is
fairly limited because after all uh the the other five bits of the round key do not influence which
s-box octant is hit and therefore we cannot we cannot leak those and there's still 80 bits left
to brute force so that's not really viable approach either so we have to we have to dive in even
deeper um so suppose that we instead of attacking the first s-box look up let's attack let's look at
um so round one s-box look up has introduced some diffusion uh in within the state byte so this
now means that the least significant bits of this byte actually do influence which octant is hit
uh during the s-box look up so we now have to account for shifting of the state bytes
um the the influence of the next round key and the diffusion of mixed column step which was a step
that's taken in between
uh and then we can extend our attack and I won't go into further details because this goes uh this
probably goes if if I would explain to myself it would go way beyond my head so I'll just demonstrate it
all right so this is
right after we got a shell on the on the radio on the encore
so this is a loading a kernel module that kicks the watchdog
and now we hijack code execution on the DSP
and next thing we do is run the side channel attack
so this is the full thing I'm showing you this because we optimize it such
that it's stupidly fast so this only takes a minute and then it gives you the key
so all the bytes in between as you see those are round key bytes
so
so
so
so
PC
so
again
.
le
Women
and
And
Mint
Drink
Drink
Now, clearly this isn't the actual Motorola key, it's just a mockup.
Of course, it wouldn't be fair if there weren't even more hurdles for us to jump over, so
it turned out there was an additional encryption layer for which we had to adapt the attack
to.
Then there was an additional obfuscation layer which stumped us for a bit, but once we observed
similarities between the loaded modules, it turns out that the obfuscation was just
a rolling XOR that incrementally calculated a checksum.
With that, we could now extract the customer encryption key in less than a minute, reverse
engineered the remainder of the module format, decrypted our target module, reverse engineered
it, and finally got the secret algorithms.
So a little recap for the journey so far.
We found a format string vulnerability in the AT interface.
On the rear connector of the radio.
To get us code execution on the baseband's application processor.
We then jumped to the DSP via shared memory, explored the cache timing side channel on
the TEE of the DSP to extract our secret algos.
And now we have them.
All right.
So that brings us to the point that we can actually start doing what we wanted to do,
and that is analyze the cryptographic primitives underpinning the security of Tetra.
And...
Is this better?
Yeah.
Okay.
All right.
So we can now finally start doing what we came here for, and that is analyze the security
of Tetra.
All the primitives are, by the way, public now, so you can get them off GitHub if you
want to take a look at it for yourselves.
I will start by explaining some things and explain some vulnerabilities that we found.
So what you see here is how this authentication is shown in the stack.
You see some boxes, TA11, TA22, and those are like black boxes.
They don't tell you how it works.
We are now able to actually inspect how these things are implemented.
And we saw that all the primitives that are marked TA something are based on a proprietary
cipher named hurdle.
It's a 16-round Faisal cipher which uses 64-bit blocks and a 128-bit key.
And the primitives based...
Called TB.
Called TB are based on very simple XOR and addition operations.
Also interestingly, we found that some of these blocks are identical or highly related, and
that will help us later.
So this is an overview of a part of hurdle.
Hurdle has an F function that combines half of the states, so 32 bits, with 96 bits of
round key information.
And it has this...
Really extensive cascading structure.
So it's very...
It's quite interesting to look at.
And I'm looking really forward to some professional cryptanalytical insights.
We could not break it.
We could, however, find the function that originally generated the S-box.
It's based on the Nyberg S-box, just like AES.
But yeah, we didn't get any further with this.
So we hope some of you guys maybe want to look into this.
We will discuss, however...
We will discuss, however...
This is an attack we found on this authentication scheme.
What you see here is how the mobile station and the infrastructure perform mutual authentication.
So they generate some random numbers, and through a cryptographic dance, they prove
knowledge of a shared secret key.
And if this authentication succeeds, it will also yield a session key, the DCK.
And below, on the bottom of this slide, you see how this DCK is constructed in terms of
these primitives.
Now that we have obtained these primitives, we can do some simplification.
We found that TA21 is actually identical to TA11, except that the RS, the random seed
supplied by the infrastructure, has a reversed byte order.
Additionally, TA22 is actually identical to TA12, and the TB4 function is nothing more
than an XOR.
So the session key is generated by XORing together.
Two.
Half session keys that were generated previously.
Now this is interesting because this allows for an attack.
Let's assume that we impersonate the infrastructure and we target a mobile station.
Additionally, let's assume that we can predict the random number that is being generated
by the mobile station.
This may seem like a bit of a stretch, but in embedded systems, random number generation
is really hard and quite often not fully unpredictable, so this may be more feasible than you might
initially think.
We can provide the mobile station with an RS, a random seed, that is a palindrome.
So it's identical in the reversed byte order as in the forward byte order.
And if we do all that, then we can simplify the DCK derivation formula to something that
has the same on the left and on the right side of the XOR operation.
And by nature of the XOR function, we end up with a zero key.
So what we have achieved in this case?
It's an authenticated channel with a mobile station with a known session key of all zeros
without even having knowledge of the original shared secret K.
So next, let's talk about identity encryption.
Identity encryption in Tetra is implemented in a primitive called TA61, and this is used
to encrypt 24-bit Tetra addresses, which you can compare to a phone number if you want.
And...
These encrypted addresses are used for a while, until a certain network key is changed.
This won't happen very often, maybe every few weeks or so.
So Tetra doesn't offer strong anonymity, but pseudonymity nonetheless.
At this point, unfortunately, we cannot disclose the implementation of TA61 due to some serious
concerns from Tetra stakeholders.
We will publish them in December, but at this point, at least we can share with you the
outline of an attack.
So that we can have an informed discussion on the security of this primitive.
And the attack looks as follows.
The CCK network key is first being used in a hurdle encryption in order to generate a
64-bit intermediate secret, which is shown here as C.
And only then, this intermediate secret is used in order to encrypt this 24-bit identity.
And this happens in a weird two rounds.
Light.
Weight.
Crypto.
Scheme.
And this is vulnerable to a meet-in-the-middle attack.
As an attacker, we can try to gather a few pairs of unencrypted identities together
with their encrypted equivalent, and start computing forward from the unencrypted one,
and backward from the encrypted one, and see, at the meeting point, which guess for
the intermediate secret C would make sense.
And this attack has a complexity of 2 to the 48th.
Which, on a regular laptop, runs in about a minute.
And after you have computed this value of C, you can instantly de-anonymize anything
that comes past on the error interface.
Also, it gives you an option to attack a hurdle encryption, because you have C, which
is the output of a hurdle encryption.
And if you can somehow break that encryption and derive what the original CCK was, there
is a very, very serious problem for Tetra.
So that's also something to investigate in the future.
Now, de-anonymization can be quite serious, depending on the use case of a Tetra network.
Tetra identities are typically distributed in ranges, so regular police forces will get
one range, while intervention teams get another range, and firefighters will get yet another
range.
So, as an attacker, if you invest some effort into identifying which ranges belong to which
kind of services, you can have a very interesting intelligence position.
This can be very useful.
It can be used, for instance, in a counterintelligence context, when you may be able to notice when
covert surveillance units are near you all the time, or it can serve as an early warning
for organized crime when intervention teams seem to pile up somewhere in the vicinity.
The attack is fully passive and can be executed with very cheap hardware, so it's very realistic
that this can be done.
Right.
So, let's talk about the actual encryption algorithms.
In Tetra, traffic is encrypted with one of four key stream generators, as Jos pointed
out previously, and we found that all of them share a very similar structure.
And depicted here is TA2.
On the top, you see the key register, an 80-bit register, that provides information
to the state register below, and eventually, the state register will output key stream,
which is then used.
for encryption of tetra traffic to us ta2 looks robust but we are not cryptographers and more
public scrutiny is needed before we can finally decide that this is all good and safe to use
but this is where it gets real interesting because we found a backdoor in the ta1 cipher
ta1 is intended for private use cases commercial use cases like private security but it's also
been distributed to like say less friendly police and military forces that europe did not have very
good footing with at the time these networks were originally conceived ta1 is advertised as having
an 80-bit key but the first thing it does is apply a secret reduction step that compresses this 80-bit
key into a 30-bit 32-bit register and from then on it will only use this 32-bit register for the
generation of keystream
so obviously this is trivial to attack nowadays you will be able to crack such a key in a minute
and get a key that works for decryption of all traffic on that frequency additionally you could
decide to actually start injecting traffic which is especially worrisome when tetra is used in
a data carrying capacity such as skada one telecontrol kind of traffic so small demonstration
that can only usually develop up to 10 to 20 percent of 조ouse driving speed
but instead of a maximum of 100 percent of the traffic down here you'll see a much larger
rate of action i'm going to give you a good example of the benefits of the technology
i'm just going to break them down you can see that as far as the time they offer you know
this is something you can move about in your system you can easily move your data around
it's a pretty basic idea i think it's a little bit different than what some would expect but
it's a very simple and simple method of using the technology that you're using the today's
military operators, private security, and harbor and airport personnel.
In addition, Tetra is used in a wide area network carrying capacity
for SCADA telecontrol of oil and gas pipelines, electrical substations,
water management, and even railway signaling.
Tetra offers confidential communication guaranteed through its so-called
Air Interface Encryption feature.
This feature encrypts Tetra traffic by means of one of four proprietary stream ciphers
TA1, TA2, TA3, and TA4.
Of these ciphers, TA1 can be exported globally with appropriate export approval
and can be used by both commercial and government parties.
As such, TA1 is used to protect select law enforcement, military and private security
radio communications, as well as SCADA radio links of global critical infrastructure.
Tetra is used in many different sectors, ranging from electrical and water
utilities to oil and gas, transport, and mining.
Since the Tetra encryption algorithms have been kept secret for over 20 years,
their security has never been properly publicly evaluated, until now.
Midnight Blue researchers have reverse engineered the algorithms and uncovered
several vulnerabilities in Tetra, including a backdoor in the TEA-1 algorithm,
which reduces its advertised key strength of 80 bits to a mere 32 bits.
This backdoor, which is festered,
and global critical infrastructure for decades, enables the interception and manipulation
of TEA-1 protected Tetra communications from anywhere within cell tower coverage,
which may be up to tens of kilometers.
Due to the simplicity of the backdoor, even attackers with limited resources,
such as a $10 radio dongle, can crack TEA-1 keys in a matter of minutes.
In this demonstration, carried out on a real network, the attacker captures traffic
and identifies messages on which to mount the attack.
Now, the attacker computes the key used on this frequency.
This will take about a minute.
Once the key has been cracked, voice communications can be intercepted
while the attack remains fully undetected, or data can be actively injected.
In the case of SCADA tele-control communications being carried over Tetra-wide area networks,
attackers can use this vulnerability to obtain direct access deep within
the operational technology networks of critical infrastructure.
Allowing them to intercept and manipulate network traffic-controlling equipment
like switchgear, circuit breakers, and valves at electrical substations or oil and gas pipelines.
Due to the highly sensitive nature of the uncovered issues,
Midnight Blue has spent more than one and a half years in a carefully coordinated disclosure process
with multiple government and industry stakeholders,
guided by the Dutch government's National Cyber Security Center.
During this process, detailed...
Oh, wow.
Thank you.
Awesome, thank you.
So, with a small recap and demonstration video, I think we made a point, right?
Well, Etsy has some interesting things to say about this.
First, they claim that we are using a very high-powered graphics card
in order to be able to attack this.
Well, in my opinion, a 2016 consumer-grade graphics card
is not that high-end, but hey, opinions may differ.
Also, they state that 25 years ago, when Tetra was standardized,
32 bits of key entropy was probably sufficient to withstand attack.
And they state that you need some pretty reasonable equipment
in order to be able to attack TEA-1.
Now, I don't think I have to explain to you that this...
Now, I don't think that this...
That I have to explain to you guys...
Thank you.
That this just doesn't make sense.
Yeah, you know, why would we make any assumptions on this?
Why would we use reasonable equipment in order to attack such a cipher?
Let's 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, ETSI, 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 backdoor a backdoor.
Furthermore, they made a number of evidently false statements,
such as claiming packet injection and TEA-1 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 TEA-1
on this beautiful machine produced in 1998, running good old Windows 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 needs
about 13 hours to go through the entire search space.
After 12 and a half hours, the key is found,
demonstrating the feasibility of cracking TEA-1 on 90s consumer hardware.
Alright ETSI, now that we've cleared up this issue,
please let us know if you'd like us to demonstrate packet injection as well.
Thank you.
Right, now, I think we've got that out of the way.
So, we discussed TEA-1, it's backdoored, it's trivially breakable.
But the other encryption algorithms should be fine, right?
There's still TEA-2 and TEA-3, which are used generally by law enforcement
and emergency services.
Well, not really.
Because we also found a protocol-level vulnerability in Tetra.
And in order to understand that, we need to dive into the standard a little bit more.
So, in Tetra, signaling is encrypted.
And only the very first part, the MAC header, is unencrypted.
The MAC header contains some high-level stuff like the length of the package
and the addressee of the message.
And everything after that is encrypted with the key stream generator.
It's important to note that Tetra messages have no authenticity or integrity guarantees whatsoever.
So, there is a CRC on the MAC level.
And you may optionally add a CRC32 in the data that's encrypted here.
But that's not a cryptographic MAC in any sense.
So, an attacker will be able to forge messages.
And whenever such a message is decrypted,
the radio will just interpret it and parse it at face value.
So, the application of the key stream works as follows.
The key stream generator function gets two inputs.
It gets a key and it gets an IV.
And this IV is intended to make sure that for each message,
a different key stream is being generated.
And in Tetra, the IV mostly consists of the network type.
So, the network type is a set of frame counters.
There's slot frame, multi-frame, all kinds of frame counters.
And these things must be known to the radio whenever he wants to perform an encryption or decryption.
So, how does he know that?
Well, because it's broadcast by the infrastructure in sync and sysinfo frames.
And once more, these messages in Tetra have no further integrity guarantees whatsoever.
So, the attack starts to be clear to some of you, maybe.
An attacker can decide to overpower the infrastructure
and target a mobile station and alter its perception of the network time.
And if you start playing with the sync and sysinfo frames with a targeted mobile station,
it will happily use those counters and start using key stream that was relevant at the time you specified to it.
And this works regardless of which key stream generator is used.
So, also on TEA2 and TEA3.
The attack outline would be as follows.
Imagine we capture an interesting message at some point in time.
It's encrypted, but we decide that we would like to have the plain text contents.
Then, at a later point in time, we identify a mobile station that we want to attack.
And it can be the same mobile station.
It can also be another mobile station.
As long as it has the same key material.
We then overpower the legitimate infrastructure signal.
For instance, by use of directional antennas or just by being closer to it than the regular cell tower is.
And from that perspective, we can start messing with the perception of time of this mobile station.
So, we can set the mobile station time all the way back to time T,
when we originally captured our encrypted message.
Now, we will somehow need to be able to
extract the key stream from the mobile station that we need to decrypt our message.
We'll get into that later.
But if we can do that, then we have one we will be able to decrypt.
Now, for the recovery of key stream,
let's start out with an assumption that we already have some key stream at our disposal.
So, we will construct a message that is of length n plus one.
So, one bit longer than the key stream we have.
Such that it has an FCS, a frame check sequence,
which is a checksum that is embedded in the encrypted part.
And it needs an acknowledgement from the mobile station upon receipt.
We can encrypt this message with the key stream we already have.
And the last bit, which we don't have, we will just guess that the key stream bit there is zero.
We send it to the mobile station.
The mobile station will decrypt the message, check the checksum,
and if everything is good, send an acknowledgement.
If that happens, we know the key stream guess was correct,
and we have now recovered one additional bit of key stream.
If we do not get an acknowledgement, we know our guess was wrong,
and we have still recovered a bit of key stream.
You can repeat this, and each time you will recover an additional bit of key stream,
up to the length you desire.
Now, this assumption of having initial key stream is nice,
but we need more.
We need to have something that actually works in order to generate this initial seed key stream.
And we are going to do that by sending 16 messages to the mobile station.
And the first four bits will all be tried.
And we add the last zero. It doesn't matter what is there.
But we will try 0000 up to 11110.
And given how Tetra works, these four bits encode the message type on the LLC level.
And what's interesting is that for these 16 messages,
there will be exactly one message that will get an acknowledgement from the mobile station.
And this is the BL data without FCS message type.
And all the other messages are either supposed to be way longer,
and thus discarded as being invalid,
or will not require an acknowledgement to be sent in the first place.
So we try these 60 messages, we will get one acknowledgement,
and that means that we will know how the mobile station decrypted this.
So we will know four bits of key stream.
That's pretty cool.
But still we need a bit more, because the shortest message we can use
for the first attack we presented here is 37 bits long.
So what we do is we recover these four bits for 10 consecutive slots.
And we then craft our 37 bits.
So we have this message with the checksum inside of it.
And we use MAC fragmentation, a fragmentation feature Tetra offers,
in order to distribute our message over all of these small slots
where we have only four bits of key stream available.
The radio will then make sure that these things are stitched back together,
will decrypt them, will validate whether the checksum makes sense.
If it makes sense, you get an acknowledgement.
The story we discussed.
This way you can easily choose for which slot you would like
to have an additional bit of key stream,
make a guess on that key stream bit,
and recover an additional bit.
So when we presented this to ETSI,
they said that's an interesting and valid theoretical attack.
But it's quite serious, because it affects all key stream generators.
So we asked them, okay, understandable,
but please provide us with a base station so we can instrument it
and validate whether this attack works.
Is this attack actually practical?
And they said, ah, lol, no.
Maybe the wording was a little different.
We tried more stakeholders, and they all kind of responded like this.
So we had to go about this in another way.
So what options do we have?
We could implement the Tetra infrastructure stack
on a software-defined radio and in that way try to target our radio.
But that sounds like an awful lot of work.
It's very complex, painstaking,
and not what we're here for, right?
So what we did is get our own base station.
Meet the Motorola MBTS.
It's old, it's heavy.
I believe it's 75 kilos or something.
It was a clear text base station,
so it doesn't support encryption,
and it's cool as fuck.
And we decided to transform this thing into an attack platform.
So a short overview of the MBTS.
It has two main components.
It has a side controller, which does all the high-level stuff,
and it also has a controller.
It also holds the firmwares for both itself
and for the base radio modules.
And these base radio modules,
you can have one or multiple of them,
they are actually connected to the antenna.
They perform modulation and demodulation,
but they also perform the encryption.
Both of these components are running on PSOS Plus
real-time operating system and based on PowerPC CPUs.
Also, they both have management consoles over a serial port,
so you can connect to the serial port.
You can also enter some passwords,
and then you're allowed to enter commands for diagnostics
and for debugging purposes.
Interestingly, both of these things use unsigned firmwares.
So let's go do some base station hacking.
We modified the firmwares in order to allow
for the implementation of a proof of concept.
And the first thing we did was implement a Tinker command,
which can be invoked from the command line.
And our Tinker command allows
for raw memory access.
So you can just enter a command, read memory,
or with another command, write to memory.
You can also execute memory by just jumping
to a random memory address as specified.
And we also added malloc and free primitive
so that you can allocate blocks of memory
for use for other stuff.
Also, we added TEA support.
We used our own reference implementation for that.
And what was very helpful is that this firmware
already supported almost the entire
suite of cryptography that's required for Tetra,
but it just had an empty stop function
for the key stream generator.
So we replaced that.
We did some more small changes,
and we had a functional encrypting base station
on our hands.
We wrote a framework that allows for the loading
of modules into the memory of the base station
and for the placement of hooks on functions
where we were either interested in debugging
or changing the behavior.
So...
Making implants for this base station
was kind of straightforward, actually.
Right.
So we then decided to continue
and start working on our proof of concept,
for which we dedicated the .ksreuse command,
which allows the base station
to suddenly change the network time
as required in order to be able to mount the attack.
And also it implements the recovery mechanisms
that I've just explained to you guys.
Once we started messing with the network time,
we saw that our radio rebooted,
our mobile radio rebooted,
and we found that it was due to some
synchronization issues in Tetra.
Certain messages are expected at certain times,
and if you mess with the timing,
then it will start misinterpreting stuff.
This can be resolved.
We resolved it by making sure our time change
is aligned to four multi-frames.
It can be done neater.
We'll get you a performance improvement,
but that's way beyond what a proof of concept should be.
So with some more tinkering,
our MTM radio gladly accepts any jump in network time,
and we can start attacking.
One last thing on the base station.
We found several vulnerabilities.
For instance, the unauthenticated firmwares,
which is quite an issue
for mission-critical communications.
An attacker could implant such a thing
and gain permanent access to a base station,
or he can just exfiltrate keys and be on his way.
Also the firmwares,
of both the site controller and the base radio,
have hard-coded, undocumented backdoor passwords.
These passwords give you an authentication level
on the command line that's even higher
than the system's owner would normally have.
Lastly, if you can crash the site controller
by some kind of unhandled exception,
it will drop to a debug shell
that allows you direct code execution and memory access,
once again allowing for key exfiltration.
So, we have looked at multiple radios,
multiple base stations,
and mobile stations at this point,
and there seems to be some kind of industry-wide issue here.
The software stacks that are being used
are really not up to standards,
and we start wondering
whether anyone is actually
pentesting these things in any condition.
In any case,
here is a demonstration video
for the key stream recovery attack.
Hi, we are Midnight Blue.
We have uncovered several serious vulnerabilities
in the Tetra radio standard,
dubbed 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 the 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 Tetra configurations, but can be resolved with a firmware update.
Further details will be disclosed on August 9th.
So, this is pretty concrete, right?
So, what would Etsy say about this?
We presented our proof-of-concept status, and now, in their public response on the vulnerabilities we uncovered,
all they have to say on this key-stream recovery issue is that our research uncovered some general areas for improvement in the Tetra protocol.
Lastly, I would like to draw your attention to TEA3.
We have analyzed it, and we have not found it vulnerable,
but there is something there.
There is something very weird going on.
Now, in the other TEAS, there is also an S-box, but these S-boxes look normal, like an S-box should look.
And in TEA3, the S-box is not a permutation, so there is one entry that is there twice.
And this is highly, highly irregular, and probably, certainly not a positive thing for the security of this algorithm.
It might be a mistake, right?
Just some random bit-flip that occurred somewhere.
Well, at least it has to be a mistake when the standard was drafted,
because if not, our radio would not be compatible with other radios in the field.
And what makes it extra suspicious is the fact that there is another small structural change
to the feedback mechanism of the key register that hides the issue.
Usually, you get state merges, and in this case, you don't.
So, there is another small difference from TEA3.
And in TEA1 and TEA2, that is here.
That kind of masks that there is something weird going on.
So, at this point, the impact is unclear, but we're really asking anyone who knows his way around these kinds of things
to take a good look at it and publish their findings.
Right, so let's discuss the coordinated vulnerability disclosure process.
We started working on this project in January 2021,
and it took us four months to get the secret cryptography out of the radar.
The rest of the year, we spent on an analysis of the ciphers,
on analysis of the protocol, and on building some proof of concepts.
At the end of 2021, in December, we contacted the Dutch NCSC,
which then started enumerating stakeholders.
And in January 2022, we got our first meetings with the Dutch police,
with ETSI, the standardization body, and with the intelligence community.
In February, we distributed a preliminary advisory,
that was to be distributed among stakeholders.
The remainder of that year, we were in touch with various stakeholders,
like manufacturers, network operators, etc. users,
in order to do our best into helping them understand the vulnerabilities
and understand mitigations that they could take.
Now, let's talk mitigations.
The key stream recovery attack can be resolved in firmware,
because the radio can be told not to trust these weird changes in network time.
It's important, however, that these patches are properly validated,
because it's a tricky thing to tackle, and it's easy to get it wrong.
Alternatively, end-to-end encryption can be used to have a secondary layer of encryption
on top of the air interface encryption.
And if you're using a tetraradio in a data-carrying capacity,
you can also consider TLS or IPSec to add additional encryption.
The TAA1 backdoor obviously cannot be resolved with a firmware patch,
because it's an essential part of the standard.
So we would recommend TAA1 users to migrate to TAA2,
or alternatively, if that's not possible, use end-to-end encryption or TAA3.
The de-anonymization attack also cannot be resolved with a firmware update.
These users will have to migrate to TAA2,
which is a new version of TAA2,
a version of the standard that ETSI has drafted and has been published last year.
This implements a new encryption mechanism for identities that should be better.
Lastly, we have the DCK pinning attack, the session key pinning attack.
This can also be resolved with a firmware update.
Alright, thanks for that.
So in the aftermath of disclosing these issues,
there was some interesting discussion
with ETSI, which we'd like to highlight.
So in Kim Zetter's interview with the ETSI Tetra chairman,
he says a couple of interesting things.
First of all, he says, well, TAA1, is it such a big deal, this backdoor,
because, you know, anyone in Europe who would need high security would be using TAA2.
Well, I mean, this is not true.
We looked through various tenders and procurement documents,
and they show that TAA1 equipment was procured by various countries,
for police and military use, in the last five years.
And these are countries like Poland, Bulgaria, Croatia, Montenegro, Moldova,
all of which are either EU countries or candidate EU countries.
And some of these have been allowed to use TAA2, according to ETSI's own standards,
as far back as 2003 or 2008.
Regardless, in the last five years, they were supplied with this backdoor algorithm within Europe.
So what happened here, we don't know, but it's not just limited to the outside of Europe.
Secondly, when it comes to the use of TAA1 in critical infrastructure,
the chairman says, well, if you're using TAA1,
well, we know that certainly a government actor could have a go at them in a short order,
because that's what the researchers have proved.
But he says, you know, you might be able to migrate away,
or, you know, are high-value targets actually using this?
Well, the problem in critical infrastructure is that you don't have a lot of choice.
You can get TAA1 or TAA3.
You're limited to TAA1 due to the export controls.
In many cases, there are no Tetra end-to-end solutions for the RTUs,
the remote terminal units that you use in critical infrastructure.
And some of the compensated controls that you might want to take,
such as TLS or IPSec on top of Tetra, might not be supported by these RTUs either.
And even if you could migrate away to TAA2 or TAA3,
sometimes this is just not possible in field.
As you can see on the snippet from the manual from one of the popular Tetra RTUs,
you pick an algorithm,
and then you stick with it.
You can't update it in the field.
So now you're stuck with this 32 bits of security.
But maybe all of the stuff we've covered, you know, maybe it doesn't matter.
Maybe it's a big nothing burger because nobody actually targets Tetra networks.
And actually, in ETSI's official statement, they say,
ETSI and TCCA are not at this time aware of any exploitations on operational networks.
Well, that's interesting because two out of five attacks are passive,
so how are you going to notice that?
And it's also not true,
because we looked through the Snowden documents,
and we found that a joint NSA and Australian Signals Directorate project
was undertaken in 2007 against the United Nations Climate Change Conference in Bali,
where they targeted the networks of the Indonesian police,
and they collected Tetra communications describing demonstration routes,
as well as the Bali chief of police's private mobile phone number.
Now, they don't go into the technical details,
so this is not proof of our vulnerabilities being exploited.
It might be, it might not be,
but it does show that Tetra networks are being actively targeted.
We also found a second reference in the Snowden documents,
where GCHQ mentions that in 2009 they undertook what they call an effects operation
called Operation Quito against Argentina
around a conflict regarding oil exploration rights tensions
regarding the Falklands or Malvinas Isles.
And here they mentioned they were collecting high priority military and leadership
communications, and that involved a number of Tetra collects.
So this shows, again, you know, Tetra networks are being targeted.
So, what's next?
Well, ETSI announced an update to the standard.
They're going to replace the TAA1 authentication suite with TAA2.
They're going to update the TAA123 algorithms with 5 to 7.
They have some mitigations around the key stream recovery attack,
and they're going to keep the new algorithms all secret again.
So, in the interview with the chairman,
the journalist asked, you know,
if you're saying the only reason these algorithms are secret
is because the government has advised it,
can ETSI actually decide to make them public on their own?
And then they say, yes, we can make that decision.
And then the journalist asks, so why don't you?
And the only answer is, well, I don't know.
So, should we trust TAA6 and 7,
especially because these will be the new export-controlled ones?
What do you think?
No.
Well, let's just ask ETSI themselves first.
So, the journalist says, should we trust ETSI algorithms going forward?
And then the chairman says, well,
we have no reason to produce dodgy algorithms, if you like,
you know, except for the ones that they did.
And then he goes further and he says,
well, these algorithms were just handed to us
and they were designed with some assistance from some government authorities.
Let me put it that way.
And a little bit later he says, well, at the end of the day,
it's down to customer organizations to ensure that things are secure enough for them.
I agree it's difficult with a private algorithm,
but the reason we have three different algorithms available
must be clear to someone that they're not all as secure as each other.
So, you're going to get three new different algorithms that are going to be private,
so make up your own mind about those ones.
In conclusion, this has been the first public in-depth Tetra security analysis
in more than 20 years.
It affects more than 100 countries, many different sectors that are critical.
We reverse engineered the secret cryptography algorithms
published on GitHub, so you can go take a look.
Multiple vulnerabilities were uncovered, both in the standard as well as equipment,
including a backdoor in TEA 1.
This has implications for voice and data communications,
as well as SCADA telecontrol communications.
Patches are available for some of the issues, while mitigations will be required for others.
And I'd like to finish this talk off with a call to action,
because there's much more work to be done on Tetra.
First of all, people need to take a closer look at the TEA algorithms,
especially that very fishy S-box in TEA 3.
See if you can get, you know, a handle on that one.
Also, take a closer look at Hurdle, the block cipher that forms the core of the authentication suite,
because an attack on Hurdle could be catastrophic for Tetra security
due to our attack on TEA 61,
which gives you a little bit of a foothold to play around with that cipher.
Secondly, if you're more of a developer,
we recommend to implement and extend the open Tetra stacks that are there.
The people at Osmocom have done some great work,
and you can go talk to the Osmocom people as well as the NLNet Foundation,
who will happily help you around, extend these open implementations.
And finally, stop doing secret cryptography, please.
It's a bad idea, it always ends in tears, and it's just not polite.
Stop doing that stuff.
Finally, if you want to read more, white papers will be forthcoming on tetraburst.com.
An overview of all the vulnerabilities in the radios and the base stations
are on midnightblue.nl slash retetra.
The algorithms are on GitHub.
If you want to ask questions to us that you don't want to ask in public,
you can always send us an email on one of the addresses below.
And if you do have questions that you want to ask in public,
I'd like to open the floor for that right now.
And that's that.