Chinese backdoor

[Razorback55]

Following the discovery of Chinese backdoors, I propose to make a list of radios with and without backdoors.

Baofeng - DM32 DM-32 256 bit Encryption Channel Setting.

DM32 DM-32 256 bit Encryption Channel Setting. After setting up the 256 bit Encryption details, I tried to use Encryption in a channel setting. When I checked the box for Encryption and entered the Encryption ID, as soon as I left that channel... it reverted to Blank. SOLUTION - Export the...

forums.radioreference.com

I asked ChatGpt:

"What is the security of AES-256 in OFB mode with a constant initialization vector?"

Answer:​

Using AES-256 in OFB mode (Output Feedback Mode) with a fixed initialization vector (IV) significantly weakens the security of the encryption, even though AES-256 itself is a strong encryption algorithm.


Here's a detailed explanation:

---

1. How OFB Mode Works (Text Description)​

• OFB turns a block cipher like AES into a stream cipher.
• Encryption and decryption are done by XORing the plaintext (or ciphertext) with a keystream that is generated from the IV and the key.
• This keystream is independent of the plaintext itself and follows this pattern:
  • First block: keystream_0 = AES_encrypt(key, IV)
  • Second block: keystream_1 = AES_encrypt(key, keystream_0)
  • Third block: keystream_2 = AES_encrypt(key, keystream_1)
  • And so on...
• This same keystream is used to XOR with plaintext to get ciphertext, or with ciphertext to get plaintext.

---

2. Why a Fixed IV is Insecure​

If you reuse the same IV with the same key, then the keystream will always be the same. This leads to several vulnerabilities:

a. Vulnerability of Stream Ciphers​

Suppose you encrypt two different plaintext messages, M1 and M2, using the same key and the same IV:

• C1 = M1 XOR keystream
• C2 = M2 XOR keystream

An attacker who intercepts both ciphertexts can compute:

• C1 XOR C2 = (M1 XOR keystream) XOR (M2 XOR keystream)
• This simplifies to: M1 XOR M2

This XOR of plaintexts (M1 XOR M2) can reveal information about both messages, especially if one of them is known or guessable (silence frames).

b. Loss of Semantic Security​

When the IV is fixed, encrypting the same message multiple times always produces the same ciphertext. This leaks information and enables pattern recognition.

c. Reveals Structure and Repetitions​

Since OFB mode does not use the message content to affect the keystream, using the same IV will result in identical ciphertext patterns for identical plaintext blocks, making repeated content visible to attackers.

---

3. Best Practice​

To maintain security with AES in OFB mode:

• Always use a unique IV for each encryption session.
• The IV does not need to be secret, but it must be unpredictable and never reused with the same key.
• It is common to send the IV along with the ciphertext (e.g., prepend or append it).

Example:

• ciphertext = IV || actual_encrypted_data

---

4. Conclusion​

AES-256 in OFB mode with a fixed IV is not secure. It makes the encryption vulnerable to keystream reuse attacks, plaintext XOR recovery, and ciphertext pattern analysis. The use of a unique IV for each encryption operation is crucial to ensure the confidentiality and security of the data.

Test with a Motorola network:

DSD+ with option -v4

MOTOTRBO network RC4 algo (CAP+ network with RAS), IV is the same every other time !!!!
Possible backdoor in the RC4 Mototrbo

+DMR slot1 BS DATA DCC=7 PI Header ECC/RAS Alg=RC4 KID=1 MI=DA6A0D98 Tgt=2001

+DMR slot1 BS DATA DCC=7 PI Header ECC/RAS Alg=RC4 KID=1 MI=2547A603 Tgt=2001

+DMR slot1 BS DATA DCC=7 PI Header ECC/RAS Alg=RC4 KID=1 MI=DA6A0D98 Tgt=2001

+DMR slot1 BS DATA DCC=7 PI Header ECC/RAS Alg=RC4 KID=1 MI=2547A603 Tgt=2001

+DMR slot1 BS DATA DCC=7 PI Header ECC/RAS Alg=RC4 KID=1 MI=DA6A0D98 Tgt=2001


Could someone test on their own Motorola RC4 and AES radios?

Could someone do the same test on their own Chinese radios in RC4, AES128 and AES256?

 

[Razorback55]

RADTEL RT-4D:



RC4 same IV !!!

Slot 1 DMR PI Header ALG ID: 0x01 KEY ID: 0x01 MI: 0x6C8AB637
Slot 1 DMR PI Header ALG ID: 0x01 KEY ID: 0x01 MI: 0x6C8AB637
Slot 1 DMR PI Header ALG ID: 0x01 KEY ID: 0x01 MI: 0x6C8AB637
Slot 1 DMR PI Header ALG ID: 0x01 KEY ID: 0x01 MI: 0x6C8AB637
Slot 1 DMR PI Header ALG ID: 0x01 KEY ID: 0x01 MI: 0x6C8AB637
Slot 1 DMR PI Header ALG ID: 0x01 KEY ID: 0x01 MI: 0x6C8AB637

AES128 same IV !!!

Slot 1 DMR PI Header ALG ID: 0x04 KEY ID: 0x03 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x04 KEY ID: 0x03 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x04 KEY ID: 0x03 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x04 KEY ID: 0x03 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x04 KEY ID: 0x03 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x04 KEY ID: 0x03 MI: 0x12345678

AES256 same IV !!!!

Slot 1 DMR PI Header ALG ID: 0x05 KEY ID: 0x05 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x05 KEY ID: 0x05 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x05 KEY ID: 0x05 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x05 KEY ID: 0x05 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x05 KEY ID: 0x05 MI: 0x12345678
Slot 1 DMR PI Header ALG ID: 0x05 KEY ID: 0x05 MI: 0x12345678

 

[Digonding]

What about my MD 380UV Plus firmware D119.024 with aes256 ?

 

[Digonding]

I also have the Radtel rt-4d firmware v3.14 2025-03-21 with aes256:

 

[Razorback55]

The P25 standard confirms that the IM should never be repeated for the same key. It's the same for the DMR standard.



The protocol accepts identical MI (IV) but the standard confirms that this gives very little real security.

 

[BinaryMode]

I entered this thread thinking the radio - if connected to the Internet - provided a "backdoor." I leave now with the affirmation that the old phrase, "you get what you pay for" is true...

 

[doriboni]

What about my MD 380UV Plus firmware D119.024 with aes256 ?

View attachment 181551
View attachment 181552
View attachment 181553
View attachment 181555
View attachment 181557
View attachment 181558
View attachment 181559

yes it's a backdoor but less serious than the fixed MI. Since bytes 3 and 4 are still identical to byte 2, the MI is 16 bits instead of 32 bits. The encryption will be the same much more often, especially if several radios communicate on the same network (birthday attack).

 

[doriboni]

I entered this thread thinking the radio - if connected to the Internet - provided a "backdoor." I leave now with the affirmation that the old phrase, "you get what you pay for" is true...

No, the statement is not necessarily true, because even when you pay very much you can have a backdoor:

Rubicon

www.cryptomuseum.com

 

[Razorback55]

yes it's a backdoor but less serious than the fixed MI. Since bytes 3 and 4 are still identical to byte 2, the MI is 16 bits instead of 32 bits. The encryption will be the same much more often, especially if several radios communicate on the same network (birthday attack).

I asked ChatGPT and it takes about 300 transmissions with a MD UV380/390 Plus to start decoding the AES256 without knowing the key:

Your radio communication system using walkie-talkies employs AES-256 in OFB (Output Feedback) mode with a 16-bit initialization vector (IV). It’s an interesting setup, but there is a critical security weakness, especially due to the small IV size, and this becomes particularly relevant when considering the birthday attack.

---

🔐 Reminder on AES-256 in OFB Mode​

• AES-256 is a symmetric block cipher with a 256-bit key. On its own, it's considered very strong.
• OFB (Output Feedback)is a block cipher mode that turns a block cipher into a stream cipher.
  • It generates a pseudo-random keystream based on the IV and the key.
  • This keystream is XORed with the plaintext to produce ciphertext.
  • The same process is used for decryption (ciphertext XORed with the keystream).

---

⚠️ The Main Problem: 16-bit IV​

• A 16-bit IV means only 2^16 = 65,536 possible IV values.
• In OFB mode, using the same IV with the same key always produces the same keystream.
• If the same IV is reused, the keystream will be reused — which is very dangerous.

---

🎂 Birthday Attack​

The birthday attack relies on the probability of collisions when choosing random IVs in a limited space.

How many IVs are needed to have a 50% chance of a collision?​

This is given by the birthday paradox approximation:


n ≈ 1.2 × √N


In our case, N = 65536 (because the IV is 16 bits), so:


n ≈ 1.2 × √65536 = 1.2 × 256 ≈ 307


That means that after about 300 messages, there's already a 50% chance that at least two IVs collide.

---

🧨 Consequences of IV Collisions in OFB​

• If two messages use the same IV and the same key, they use the same keystream.
• XORing the two ciphertexts cancels out the keystream:
  C1 XOR C2 = (P1 XOR M) XOR (P2 XOR M) = P1 XOR P2
  (Where C1 and C2 are ciphertexts, P1 and P2 are plaintexts, M is the keystream.)
• The result is the XOR of the two plaintexts. This can be analyzed statistically, and if one of the plaintexts is known or guessable (e.g., silence frames), the other plaintext can be recovered with a simple XOR.

---

🔓 Example of an Attack​

1. The attacker intercepts multiple encrypted messages.
2. They find two messages with the same IV.
3. They compute the XOR of those messages — which gives P1 XOR P2.
4. If one message is known or guessed (e.g., silence frames), they recover the other message instantly.

💬 Summary​

Your current setup using a 16-bit IV with AES-256 in OFB mode is critically vulnerable. After only a few hundred messages, it's very likely that IVs will repeat, exposing your system to passive attacks (interception + analysis). Even though AES-256 is secure as a cipher, using a weak IV undermines the entire system and makes it insecure in real-world scenarios.

 

[dkcorlfla]

No, the statement is not necessarily true, because even when you pay very much you can have a backdoor:

Rubicon

www.cryptomuseum.com

My house > $400,000 and it has a backdoor ;-)

 

[BinaryMode]

No, the statement is not necessarily true, because even when you pay very much you can have a backdoor:

Rubicon

www.cryptomuseum.com

But there is no backdoor.

The crypto in the cheap radios is just made cheap. Or they don't know how to implement the encryption properly.

I mean, do these Chinese manufactures of cheap radios expect the U.S. government to use their products?

Now when it comes to silicon that's a different story. As I'm pretty sure server hardware and who knows what else has backdoors. So you always want to monitor what goes in and out of the system. It's why I want to eventually replace any TP-Link crap switches I have with Cisco. Have one replaced now. But even then, can I still trust Cisco? After all, it's ALL made in China.

I just wouldn't call it a backdoor but more of a flaw.

 

[doriboni]

But there is no backdoor.

The crypto in the cheap radios is just made cheap. Or they don't know how to implement the encryption properly.

I mean, do these Chinese manufactures of cheap radios expect the U.S. government to use their products?

Now when it comes to silicon that's a different story. As I'm pretty sure server hardware and who knows what else has backdoors. So you always want to monitor what goes in and out of the system. It's why I want to eventually replace any TP-Link crap switches I have with Cisco. Have one replaced now. But even then, can I still trust Cisco? After all, it's ALL made in China.

I just wouldn't call it a backdoor but more of a flaw.

As far as radios are concerned, I don't think it's a flaw because this backdoor was reported to Anytone in 2019 who corrected it some years later, but since then the other manufacturers have been doing the same thing again. It seems weird that a known flaw is added in products over and over again.

Anytone - Anytone 878 RC4 and AES

Is there a way to switch between RC4 and AES without going into the CPS and reprogramming the radio?

forums.radioreference.com

Also, noticed something interesting. Try enabling AES on the Anytone radio, and analyse the full Tx traffic in DSD+ (use the -v4 option). Message ID (MI) seems to be a constant "12345678" no matter what key or channel settings, which if I read this correctly means the IV is constant. Yes, DMR's MI is a measly 32 bits of IV, but keeping it constant for all transmissions seems like a possible issue (known plaintext attacks?).

Do correct me if I am mistaken.

 

[Ubbe]

It seems weird that a known flaw is added in products over and over again.

They probably copy each others firmware and reverse engineer it and doesn't do much development themselves when it comes to different data protocols. If one flaw are found in the actual protocol then it will usually be found in all Chinese products.

/Ubbe

 

[doriboni]

They probably copy each others firmware and reverse engineer it and doesn't do much development themselves when it comes to different data protocols. If one flaw are found in the actual protocol then it will usually be found in all Chinese products.

/Ubbe

Yes that's also a possibility but in the end you can't trust Chinese security products because they could have copied Motorola properly.
Hytera does it well, why not the other Chinese?

 

[doriboni]

They probably copy each others firmware and reverse engineer it and doesn't do much development themselves when it comes to different data protocols. If one flaw are found in the actual protocol then it will usually be found in all Chinese products.

/Ubbe

Apparently all the firmware comes from the same place, from the chip manufacturer or the Chinese government. It seems implausible that the chip manufacturer or the Chinese government doesn't know anything about cryptography. It then seems more logical that the backdoor is voluntary.

DMR SMS support? - OpenGD77

by G4EML » Fri May 17, 2024 9:14 am

Retevis doesn't write the firmware for its DMR radios. Most of the low cost Chinese radio companies use firmware written by the same third party company. This company is unknown but we suspect it is connected to the chip manufacturer or government.

About the only Chinese company that seems to write it's own firmware is Anytone.

Colin G4EML

Well, I would not be surprised if the government was involved because of how secretive the manufacturer is about their documentation of the baseband IC. I'm sure the CCP does not like people talking to each other with encrypted radios, maybe the C6000 includes some backdoors, maybe you can send it a special command over the air that disables encryption or forces it to send out unencrypted frames in parallel on the other timeslot, and of course you wouldn't want to publish that feature in a datasheet..