Overview
.jpg)
After we published our TETRA:BURST research in 2023, we hoped several points about TETRA security would quickly become universally known and understood. While most parties understood the backdoor we uncovered in TEA1, another important takeaway has seemingly failed to register broadly: Authentication in TETRA provides no authenticity guarantees for messages/traffic.
While we reported this issue in our initial research made public in 2023, it was only assigned CVE-2025-52944 after we implemented a practical demonstration to disprove vendor and system integrator assertions that this was infeasible.
The consequence of this basic security flaw is that malicious traffic can be injected into TETRA networks and authentication doesn't prevent this. This has particularly serious consequences for TETRA networks where voice or data traffic has direct operational consequences, such as security dispatching and SCADA WANs.
In this blog post, we will discuss the limitations of authentication and its potential impact.
TETRA was standardized by the European Telecommunications Standards Institute (ETSI) in 1995, is used in more than 100 countries, and is the most widely used radio communication standard for emergency services. It is, however, also widely used in critical infrastructure, both to carry voice (security personnel, engineers, operators) and data transmission, including in a machine-to-machine capacity such as SCADA WANs.
TETRA security consists mainly of encryption and authentication components. There are several encryption algorithms; TEA1 through 4, augmented with the newer algorithms TEA5 through 7, standardized in 2022. The different variants are strictly divided by target audience, and the stronger TEA2 and TEA3 algorithms were reserved for EU or EU-aligned emergency services.
As a result, most critical infrastructure parties have historically operated with TEA1 or without encryption at all. Since TEA1 is backdoored (broken within a minute, and ham radio enthousiasts have published open source attack tools), these parties do not have any confidentiality guarantees. However, for many critical infrastructure operators confidentiality is often a far less pressing issue than message authenticity and integrity.
In TETRA, the authentication looks as follows:
We see the infrastructure initiates the authentication by sending a D-AUTHENTICATION DEMAND message, containing a random and a challenge. The client responds with a U-AUTHENTICATION RESPONSE containing response RES1, proving the client knows its authentication key K. The client also includes RAND2, which is a challenge for the infrastructure. The D-AUTHENTICATION RESULT with an R1 bit, indicating that the infrastructure was okay with the client's RES1. It also holds RES2, proving to the client that the infrastructure also knows the shared secret K.
After the authentication is finished, the base station will accept the ISSI (the "TETRA phone number") of the newly authenticated radio on the network, allowing it to place calls, subscribe to groups, send SDS text messages, etcetera.
But: what is to stop an adversary from simply taking an already-authenticated ISSI, and sending messages using this impersonated ISSI?
The brief answer: Nothing.
In non-class3 networks, the TETRA authentication only restricts registration on the network, and plays no role in protecting authenticity or integrity of regular traffic or signalling. It simply keeps honest radios honest.
When we observe traffic on an unencrypted network, we see downlink MAC-RESOURCE messages being transmitted. This can be done with open-source tooling, like osmocom-tetra or the more feature-complete fork by SQ5BPF, which also features the telive2 live dashboard.
1BURST
2TMV-UNITDATA.ind 15/11/1/000 AACH CRC=1 ACCESS-ASSIGN
3ACCESS-ASSIGN PDU: ACCESS1: A/10 ACCESS2: A/10 00001010001010
4CRC COMP: 0x1d0f OK
5SCH/F 15/11/1/000 type1: 0000[..]0000
6TMV-UNITDATA.ind 15/11/1/000 SCH/F CRC=1 RESOURCE
7RESOURCE Encr=0 Addr=SSI + Usage Marker(100/U7) ChanAlloc=Replace (..): 0010[..]0010
8TM-SDU(BL-UDATA) l3len=74 0100[..]0010
9TL-SDU(CMCE): 0100[..]0010 D-SETUP
10Call identifier:4 Call timeout:7 Hookmethod:0 Duplex:0
11Basicinfo:0x04 Txgrant:3 TXperm:0 Callprio:0
12NotificationID:0 Tempaddr:0 CPTI:1 CallingSSI:910001 CallingExt:0
In this (slightly abbreviated) log fragment, we see exactly how a D-SETUP message (the message type used for setting up a call) is decoded as it is captured. The RESOURCE is decoded at the MAC layer, which is also where encryption/decryption happens, if enabled. In our case, this is a plaintext message.
In lines 9-12, we see the contents of the D-SETUP message. Importantly, the CallingSSI (here: 910001) designates which radio opens this call. As such, the CallingSSI should be that of an authenticated radio. However, nothing in the message ties it to the actual owner of that ISSI. Anyone can inject malicious traffic by sending the SSI registered on the cell.
There are a few little caveats, like that the legitimate radio may start interfering, but there's ways around that. However, there's more.
In the previous scenario, we have hijacked the ISSI of an authenticated radio, connected to the same cell tower. However, in practice, that's often not required. In order to reduce load on the authentication centre, many base stations don't require a re-authentication whenever a radio is roaming from one cell tower to the next. Instead, the authenticated state is implied as the infrastructure remembers the radio to have authenticated elsewhere, in the past.
A full authentication trace consists of a U-LOCATION UPDATE DEMAND sent by the radio, signalling that it wishes to connect to the network. The infrastructure may then send a D-AUTHENTICATION DEMAND message to kick off the authentication process, as was shown in the figure before. If all goes well, a D-LOCATION UPDATE ACCEPT message will ultimately signal the authentication was completed and the radio is accepted on the network.
However, on many real-world networks, we only see very few D-AUTHENTICATION frames when compared to the number of D-LOCATION UPDATE ACCEPT messages. The infrastructure may decide to skip re-authentication as the radio was known to be previously authenticated and registered to another cell tower. A visualization of this abbreviated message flow is shown below.
1Client Base station
2 | U-LOCATION UPDATE DEMAND |
3 | -----------------------> |
4 | |
5 | D-AUTHENTICATION DEMAND | SKIPPED
6 | <----------------------- |
7 | |
8 | U-AUTHENTICATION RESPONSE | SKIPPED
9 | ------------------------> |
10 | |
11 | D-AUTHENTICATION RESULT | SKIPPED
12 | <---------------------- |
13 | |
14 | U-AUTHENTICATION RESULT | SKIPPED
15 | ----------------------> |
16 | |
17 | D-LOCATION UPDATE ACCEPT |
18 | <----------------------- |
We see that the full registration and authentication flow is drastically cut short. The infrastructure does not ask for an authentication, and instead immediately accepts the client onto the network.
This opens an even more powerful attack method: impersonate an SSI registered anywhere on the network, and send a U-LOCATION UPDATE on its behalf. The infrastructure skips over authentication, as it will assume the attacker is actually the original radio switching over to a new base station. The original radio is deregistered, without receiving a notification of this event. The attacker has effectively quietly taken over the authentication state of the original radio, on a different cell tower.
These issues are very relevant for an attacker that injects malicious traffic onto a TETRA network. In the past, we have demonstrated injection attacks are feasible, using a representative OT setup featuring a SCADA system connected to a Motorola MTM5400 which serves as a data modem to our lab TETRA network (using a Motorola TETRA base station). A second MTM5400 picks up the IEC-104 SCADA telecontrol signalling, and sends it to a Schneider Electric M340 PLC with RTU module. The PLC can take switching actions to either supply or disrupt power flow to our demonstration Christmas village. We demonstrate how we first observe traffic, craft a relevant new message, and successfully inject it into the TETRA network, ultimately disrupting power flow to our demo village.
This injection risk is not just limited to TETRA traffic carrying SCADA WANs or railway signalling, but also to TETRA networks where alarm messages or voice traffic are intimately tied to safe operations and may lead to serious disruptions. This is the case for TETRA systems at many airports, harbors, railway operators, and civil defense siren systems which rely on trustworthy TETRA voice and data communications and are at risk of injection attacks that would disrupt security dispatching, baggage or apron control, and emergency evacuation operations.
A concrete example of this is found in the 2026 attack on the TETRA network of Taiwan High Speed Rail (THSR) where an unauthorized alarm message caused the railway dispatching centre to shut down multiple high-speed trains.
In this blog post, we focus on networks falsely relying on TETRA network authentication to provide perceived authenticity and integrity guarantees. However, encryption may automatically also provide some integrity guarantees. We'll briefly outline what encryption will, and will not, achieve.
With respect to the choice of cipher: TEA1 is backdoored, and TEA4 and TEA7 are also intentionally weakened. Since these algorithms can be broken, confidentiality should be considered equivalent to an unencrypted network from both a confidentiality and authenticity/integrity point of view.
But what about other security classes? Class 2 networks use a static cipher key, which is applied indiscriminately on traffic without any explicit ties between network authentication and message encryption. Class 3 networks actually bind the authentication to traffic and signalling encryption through its key derivation procedure. However, these are still no strong authenticity and integrity guarantees: any attacker capable of breaking the encryption can always inject traffic without having to bother with network authentication.
For those stronger configurations, the attacker may still have ways to inject malicious traffic
If there is one sentence you should take away from this blog post: TETRA does not provide message authenticity & integrity guarantees, even with authentication enabled. However, TETRA in combination with air interface encryption can increase resistance to traffic injection, but the actual resilience is highly dependent on network configuration, mobile device patch level, and use case.
For those interested in advancing their broader RF security skills, including analyzing digital trunking technologies such as TETRA, DMR, and P25, Midnight Blue will be delivering its Red Team SIGINT training at several conferences:
This practically-oriented course, which has sold out multiple times to stellar reviews, is aimed at red team operators and pentesters and will teach attendees the fundamentals of RF, SDR, and SIGINT before quickly moving on to effective guidance on identifying and decoding unknown signals as well as exploiting common pitfalls in RF security.
Where other SDR trainings tend to focus on enterprise and IoT RF protocols such as 4G/5G, WiFi, RFID, and BT, this training focuses on important but rarely addressed RF technologies such as automotive, aviation, marine, and physical access control RF protocols and mission-critical radio (e.g. TETRA, DMR, P25) used by police, military, private security, and critical infrastructure.
Hands-on exercises such as intercepting and decrypting handheld radio comms, analyzing drone video feeds and maritime RF communications, and breaking automotive security systems are alternated with thorough overviews of relevant RF protocols and their security posture as well as case studies of real-world RF attacks on railways, water utilities, drones, and police/military radios.
An overview of the course can be found here.
All items
