In 2014 i have released the first publicly available software that could monitor unencrypted voice calls on a TETRA network (and also some data: SDS, status etc). This software was called telive.

Previously the network operators intentionally did bother with encryption. This pushed network operators to use it. The world got more secure.

While better than nothing, this encryption was proprietary. The public could not audit it. Historically when the algorithm was not disclosed it was often found to be weak (such as A5/1 in GSM).

In 2023 Midnight Blue released their fantastic work on reverse engineering the TETRA encryption algorithms. They published an implementation of TEA1-4 and also found deliberate weakening of the TEA1 protocol.

So at the turn of 2025/2026 i have released an experimental version of my software which can monitor encrypted calls on a TETRA network. This is of course only if you know the encryption keys (see below on how to obtain them). Also i added support for the reduced keys for TEA1. And also released software to recover the reduced key from on-air traffic.

Hope this will further push operators to step up their security.

Installation and use

The installation is the same as in case of mainline telive and companion software.

Install the telive software from here: GitHub – sq5bpf/telive-2: Tetra live monitor – experimental version using the script in scripts/install_telive.sh . best use a cleanly installed Debian 12.

Try it with an rtl-sdr dongle on an unencrypted network (just like you would use regulat telive), verify that it works with a 1 channel receiver.

Using it to decrypt calls

First of all ask the owner of the network for permission before doing anything with it.

Ask the network owner to give you the encryption key.

This can be tricky because often the key is generated in a keyloader device, which is then used to load it onto base stations and radios. The key never leaves the device in plaintext form.

Please search online forums for info how to obtain this key. A key can be manually entered into the keyloader and then loaded onto the devices.

See below for how to test TEA1 weakness.

Make a backup of sample_keyfile. Edit it to add the network parameters and key.

Start receiver1udp again and see of calls are being decrypted.

Testing TEA1 weakness

As always ask the network owner for permission.

For testing TEA1 weakness, please ask the network owner to temporarily change the encryption to TEA1 (because for sure it is using a stronger algorithm, the vulnerabilities are publicly known since 2023).

I have released TEAtime – software which can be used to recover the short 32 bit key. The process is described in detail in the TEAtime software README.md. Remember to always test the recovered key with a few more candidates in verify mode to see if it is really correct.

Enter the network parameters and recovered key (12345678 in this example) into test_keyfile. For key_num use the CCK ID in from the receiver output (42 in this example, but often it’s 0). Example sample_keyfile:

network mcc 0123 mnc 1337 ksg_type 1 security_class 2
key mcc 0123 mnc 1337 addr 00000000 key_type 16 key_num 42 key 12345678000000000000

Run receiver1udp again and see if audio is being heard from telive.

FAQ

Do I have to get permission from the network operator?

Probably yes. Please obey the laws of the country you are in. Also please provide your findings to the network operator and point them to this software so that they can audit their network.

Is my network using TEA1?

Probably no. TEA1 has been deliberately weakened, and the exact details are known since 2023. Competent network operators have upgraded long ago.

You can try to run TEAtime in crack mod on key recovery candidates. And then run it with the recovered key in verify mode on a few more candidates. If the keystream xor ciphertext value is the same, then it may be a TEA1 key.

What encryption is my network using?

Unfortunately this is hard to tell. The network doesn’t transmit this info.

In short:

• if you can get it to decrypt, then the algorithm and parameters are ok
• If it is a goverment network in the EU it should be using TEA2
• If is some other network, it should be migrated to TEA3 or TEA4

Does it run on xxxx (something other that debian 12)?

Probably not without some tweaking, but i will try to add support for other distributions in the future.

I don’t know how to compile/run this?

This is aimed at experienced users only. In the future i might write some better documentation.

So why was this released?

It was released to get feedback from users who are already proficient with linux, telive and tetra, and preferably are testing this on their own network (which they can reconfigure to test different scenarios).

How can I help?

If you own tetra equipment, them please set up a TEA1 network, generate some test traffic in it (voice and SDS), record the bitstream and publish it (anonymously if you want). This way it can be used as test data.

If you find this description unclear, please email me how to improve it.

We are using TEA1, you are undermining out security!

No, you are undermining it. The information about TEA1 weaknesses was released publicly in 2023, this software is released 2.5 years later.

If you did know this, you were knowingly putting your users at risk, also by providing them with a false sense of security.

If you did not know this, then you are not doing cybersecurity due diligence properly. This info was in TCCA and vendor recommendations, conferences, even public media covered this. By skipping due diligence you were knowingly putting your users at risk.