.jpg)
Midnight Blue presents new research on the security of TETRA, including on the elusive TETRA End-to-End (E2EE) encryption mechanisms that are commonly encountered in the most sensitive of use cases. TETRA E2EE is an additional layer of security on top of the Air Interface Encryption (the TEA suite of algorithms) intended for end users like intelligence agencies and special forces. The design of TETRA E2EE is proprietary and NDAs have prevented public scrutiny.
Midnight Blue has managed to obtain, reverse engineer and analyze a popular TETRA E2EE solution in order to assess its security.
On this page, we publish the TETRA E2EE details together with a security analysis uncovering three vulnerabilities.
Furthermore, we identified several serious new issues in the general TETRA standard. The first pertains to the feasibility of packet injection, demonstrated in the context of a SCADA WAN network. We also reveal a critical vulnerability in multi-cipher networks, and new, highly efficient keystream recovery attacks.
Lastly, we demonstrate how ETSI's fix for CVE-2022-24401, introduced in a recent revision of the standard, is insufficient.
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 police radio communication system. Like its North American counterpart P25 and other standards such as DMR and TETRAPOL, TETRA can be used for voice and data transmission, including in a machine-to-machine capacity. ETSI standardized the TETRA Air Interface Encryption (AIE) mechanism, facilitating encryption between the mobile radio and the infrastructure, which we previously assessed as part of our TETRA:BURST research.
On top of the AIE encryption, an additional End-to-End Encryption (E2EE) mechanism may be used for the most sensitive use cases, such intelligence agencies, special forces, and covert units.
While ETSI is responsible for the main TETRA specification, it does not govern the TETRA E2EE specification. Instead, ETSI's TETRA standard merely facilitates the integration of proprietary E2EE solutions into TETRA, and provides (very limited) guidance on how an E2EE solution could be designed. The TETRA E2EE protocols, introduced in the early 2000s, are defined by The Critical Communications Allicance (TCCA), which has close ties to ETSI, manufacturers and end users alike. The TCCA outlines the E2EE protocols in a series of SFPG recommendation documents which are subsequently implemented by vendors such as Sepura, Sectra, Airbus, Leonardo, Motorola, and Hytera.
Vendor implementations, however, may differ, and solutions are sometimes mutually incompatible. Motorola offers their UCM or CRYPTR Micro hardware security modules, Sepura and Hytera offer their Embedded End-to-End solution, and various smartcard (SIM)-based solutions by Sectra and Airbus are available. After an initial attempt to attack the Motorola CRYPTR Micro, we chose to reverse-engineer the Sepura Embedded E2EE solution, a popular software-based implementation based on a familiar Texas Instruments platform, the OMAP-L138. We believe this implementation closely adheres to the SFPG's recommendations and while we haven't assessed other E2EE implementations we consider it likely they are affected by these or similar issues.
Typical for the opaque and proprietary standards and guidance surrounding TETRA, the E2EE cryptographic primitives and mechanisms are omitted from public specifications and are only available under highly restrictive NDAs. The widespread adoption of TETRA, the often sensitive nature of communications, and TETRA's dubious track record (including the backdoor in TEA1), highlight the necessity of a thorough independent assessment. This became even more pressing since E2EE is considered a mitigation for our previous TETRA:BURST vulnerabilities.
In order to shed light on the security of this important technology, Midnight Blue was granted funding by the non-profit NLnet foundation as part of its European Commission supported NGI0 Entrust fund. Midnight Blue managed to reverse-engineer and analyze the Sepura Embedded End-to-End solution, and also further investigated the broader TETRA standard and ecosystem.
The identified vulnerabilities are outlined below. The Sepura device vulnerabilities are described on this page.
TETRA end-to-end encrypted voice streams are vulnerable to replay attack. Furthermore, an attacker with no knowledge of the key may inject arbitrary voice streams, that are played back indistinguishably from authentic traffic by legitimate call recipients.
Low
Loss of authenticity
Active
TETRA end-to-end encryption algorithm ID 135 refers to an intentionally weakened AES-128 implementation which has its effective traffic key entropy reduced from 128 to 56 bits, rendering it vulnerable to brute force attacks.
Critical
Loss of confidentiality / integrity
Passive / active
End-to-end encrypted TETRA SDS messages feature no replay protection, allowing for arbitrary replay of messages towards either humans or machines.
Low
Loss of authenticity
Active
TETRA networks that support multiple Air Interface Encryption algorithms are vulnerable to key recovery attacks since the SCK/CCK network key is identical for all supported algorithms. When TEA1 is supported, an easily recovered TEA1 key (CVE-2022-24402) can thus be used to decrypt or inject TEA2 or TEA3 traffic on the network.
Critical
Loss of confidentiality / integrity
Passive / Active
The TETRA protocol lacks message authentication and therefore allows for the injection of arbitrary messages such as voice and data. Message injection is possible regardless of whether client authentication is enforced by the network.
Critical
Loss of authenticity / partial loss of confidentiality
Active
MBPH-2025-001
ETSI's fix for CVE-2022-24401 (that found its way to firmware updates) is ineffective in the prevention of keystream recovery attacks.
Critical
Loss of confidentiality / authenticity
Active
No CVE has been granted yet for ETSI's insufficient mitigation of our previous TETRA:BURST finding CVE-2022-24401. In order to streamline communication regarding the issue, we have assigned it a temporary placeholder reference. If a CVE becomes available, we will update this page.
All listed vulnerabilities were validated in practice and found exploitable through practical experiments carried out either on our lab setup with a real TETRA base station or on real-world networks.
We have recorded several demonstration videos. The first demonstrates E2EE voice injection (CVE-2025-52940) on our lab setup using Sepura Gen 3 handheld radios, showing the injection of attacker-controlled voice into an end-to-end encrypted talkgroup. In the second video, we demonstrate packet injection (CVE-2025-52944) in the context of an OT scenario with maliciously injected SCADA telecontrol traffic. Third, we demonstrate how ETSI's mitigation for our previous keystream recovery attack (CVE-2022-24401) is insufficient to prevent attack.
The vulnerabilities presented on this page constitute the result of about one year of research, followed by a six-month coordinated disclosure process. We will fully disclose our research results and present our work at various conferences throughout the year. Below you will find a selection of the conferences where (varying aspects of) the vulnerabilities are presented.
Below is a link to the slides as presented at Black Hat USA 2025. Our implementation of the (Sepura Embedded) End-to-End cryptographic primitives and protocol will be made public shortly, together with a technical whitepaper. Publication is scheduled for August, 11th.
The impact of the 2 TETRA 2 BURST vulnerabilities depends on the use-cases and configuration aspects of each particular TETRA network. In this section, we briefly go through relevant considerations for each of the vulnerabilities.
Given the generally very high security requirements of users that decide to adopt TETRA E2EE solutions, a careful risk assessment on a case-by-case basis is needed. Voice replay or injection scenarios (CVE-2025-52940) can cause confusion among legitimate users, which can be used as an amplifying factor in a larger-scale attack. TETRA E2EE users (also those not using Sepura Embedded E2EE) should in any case validate whether they may be using the weakened 56-bits variant (CVE-2025-52941). Note that these still use 128-bit keys, however, the traffic encryption keys provide an effective 56 bits of security. Furthermore, the E2EE SDS replay vulnerability (CVE-2025-52942) may be serious where end-to-end encrypted SDS messages are used for carrying control data. All E2EE vulnerabilities apply to Sepura Embedded E2EE, and may or may not apply to other TETRA E2E solutions. Lastly, the TETRA Air Interface Encryption provides some degree of additional protection, although many caveats exist. These range from the backdoored TEA1 cipher (CVE-2022-24402) to several keystream recovery attacks (CVE-2022-24401, MBPH-2025-001) and injection vulnerabilities.
In addition, we demonstrated the feasibility of malicious packet injection on TETRA networks (CVE-2025-52944). This finding impacts all TETRA users, as signalling traffic may be forged by an attacker. Downlink traffic injection is typically feasible using plaintext traffic, as we found radios will accept and process unencrypted downlink traffic even on encrypted networks. For uplink traffic injection, keystream needs to be recovered. Multiple methods exist, ranging from key recovery (for the TEA1 key) to keystream recovery (for TEA2, TEA3 and others) to coercing a radio to reveal uplink keystream through injection of carefully chosen downlink traffic. Such attacks should be prevented through ETSI's mitigation for CVE-2022-24401 (part of the 2023 TETRA:BURST vulnerabilites). However, we demonstrate this fix to be insufficient (MBPH-2025-001), which implies that radios remain vulnerable to keystream recovery attacks.
The impact of CVE-2025-52943) is critical for networks that attempt to mitigate the vulnerability of TEA1 (CVE-2022-24402) through employing a dual-cipher (for example, TEA1 and TEA3) network. In such a scenario, the TEA3 network key can be trivially recovered, breaking confidentiality and exposing the network to packet injection attacks. Only when TEA1 is fully disabled, and all network keys have subsequently been renewed, the risk ceases to be exist.
Networks that use TETRA in a data carry capacity are especially impacted due to the potential risks associated with packet injection. This allows attackers to not only intercept radio communications of private security services at harbors, airports, and railways, but additionally inject malicious data traffic used for monitoring and control of industrial equipment. As an example used for our demonstration, electrical substations can wrap telecontrol protocols in encrypted TETRA to have SCADA systems communicate with Remote Terminal Units (RTUs) over a Wide-area Network (WAN). Decrypting this traffic and injecting malicious traffic allows an attacker to potentially perform dangerous actions such as opening circuit breakers in electrical substations or manipulate railway signalling messages.
As shown in the table below, mitigations are available for several of the issues, while compensating controls need to be considered for others. A detailed advisory has been distributed to relevant stakeholders through the Dutch National Cyber-Security Centre (NCSC) and distributed to stakeholders and Midnight Blue customers and relations during the CVD process.
CVE-2025-52940
Migrate to scrutinized, secure E2EE solution (contact us)
Tailor based on risk assessment
CVE-2025-52941
Migrate to non-weakened E2EE variant
Tailor based on risk assessment
CVE-2025-52942
Migrate to scrutinized, secure E2EE solution (contact us) or add strong application-layer security mechanisms robust against SDS replay attacks
Monitor out-of-order SDS sequence numbers
CVE-2025-52943
Disable TEA1 support and rotate all AIE keys
Adjust OPSEC based on risk assessment
(consider traffic equivalent to cleartext)
CVE-2025-52944
When using TETRA in a data carrying capacity:
add TLS/VPN layer on top of TETRA.
Other cases: Tailor based on risk assessment
Adjust OPSEC based on risk assessment
CVE-2022-24401
MBPH-2025-001
Wait for availability of radio firmware patch,
deploy patch to all radios
Adjust OPSEC based on risk assessment
(e.g. regarding subscriber identity management)
Midnight Blue adheres to the Dutch NCSC’s CVD guidelines, which stipulate a 6-month embargo period for hardware and embedded systems vulnerabilities. At the time of reporting, an advisory has been provided to the NCSC, which was further distributed to asset owners and stakeholders. Furthermore, Midnight Blue has informed relevant customers and relations directly to ensure sufficient time for a thorough understanding of the issues at hand, as well as for mitigation of any unacceptable risk.
Feb 2024
Started work on TETRA End-to-End Encryption
May 2024
Finalized initial re-implementation of Sepura Embedded End-to-End
Started security analysis
Jan 2025
Finalized security analysis of Sepura Embedded End-to-End
Finalized security analysis of additional non-E2EE TETRA vulnerabilities
06-02-2025
Detailed technical advisory provided to NCSC-NL for distribution to stakeholders and asset owners
xx-2025
Several meetings with law enforcement, ETSI, vendors, and other stakeholders regarding vulnerabilities and mitigation
07-08-2025
Technical research embargo lifted
Black Hat USA 2025 presentation
If you operate or use a TETRA network, you are certainly affected by CVE-2025-52944, in which we demonstrate it's possible to inject malicious traffic into a TETRA network, even with authentication and/or encryption enabled. Also, CVE-2022-24401 likely affects you, as it allows adversaries to collect keystream for either breach of confidentiality or integrity. If you operate a multi-cipher network, CVE-2025-52943 poses a critical security risk. Lastly, if you are using end-to-end encryption, you may be affected by CVE-2025-52940, CVE-2025-52941 and CVE-2025-52942. Contact us for a no-strings-attached chat.
There is no immediate evidence of these vulnerabilities being exploited in the wild, however, we have received reports of heightened interest in attacking TETRA networks by nation-state level adversaries.
Manufacturers have in the past attempted to fix CVE-2022-24401, however, we show that fix to be ineffective. The remaining vulnerabilities cannot easily be patched and as such, to the best of our knowledge, no fixes can be made available. However, there are certainly ways to mitigate issues; see our Mitigations section or reach out.
We reverse-engineered an embedded end-to-end solution from a Sepura handheld, which we believe to closely adhere to the TCCA recommendation. However, other manufacturers have different solutions that may or may not be vulnerable to the issues outlined on this page.
While air interface encryption indeed makes the E2EE voice injection / replay attack more complex, there are many ways to defeat the air interface encryption. As such, on the majority of network configurations, this does not fully prevent attack.
The technical details of these vulnerabilities and different aspects of the research that led up to their discovery have been published at the 2025 edition of Black Hat USA and WHY2025. Further materials may be made available in the close future, in which case this page will be updated.
Proof-of-concept attack code will not be released due to the potential for abuse.
Official advisories should become available through the central MITRE CVE entries for the following CVE numbers: CVE-2025-52940, CVE-2025-52941, CVE-2025-52942, CVE-2025-52943, CVE-2025-52944, CVE-2022-24401. Note that the last CVE number was part of our earlier TETRA:BURST research, however, we now demonstrate ETSI's proposed fix is ineffective in preventing attack.
While we are not pushing to 'brand' this vulnerability, we did require some kind of 'handle' to collectively refer to the research. However, if you like, you are free to grab and use the 2TETRA:2BURST vector image at the top of this page. Rights waved via CC0 license.
This research was supported by the NLnet Foundation with financial support from the European Commission’s Next Generation Internet Zero Entrust programme. We would like to thank Michiel Leenaars from the NLnet foundation for his support during the grant application, project management, and later coordinated disclosure process. We would also like to thank the Dutch NCSC for their support and collaboration during the coordinated disclosure process.
All items
