Baofeng DM32 DM-32 256 bit Encryption Channel Setting.

[N0OVC]

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 Channel Info to a CSV file and manually put in your Encryption ID info. Import that Channel CVS back into the CPS and it will stay.

CPS 1.28
Firmware DM32.01.01.040

 

[doriboni]

The bug will surely be fixed in future updates.
On the other hand you are aware that it is not a real AES256 that you have? it looks like AES256, it tastes like AES256 but it's not AES256 and it's decryptable in a few minutes if you intercept about thirty conversations of a few seconds.

 

[doriboni]

On the other hand, your Anytone 878 contains the real AES256 and it is able to communicate with the fake AES256 of your Baofeng.

 

[noamlivne]

The bug will surely be fixed in future updates.
On the other hand you are aware that it is not a real AES256 that you have? it looks like AES256, it tastes like AES256 but it's not AES256 and it's decryptable in a few minutes if you intercept about thirty conversations of a few seconds.

If it is not real AES256, what is it really?

 

[exkalibur]

If it is not real AES256, what is it really?

It isn't "fake AES", don't feed the trolls. The DM32 using AES works just fine with a Motorola XPR7550 and a Hytera PD682. If that isn't real AES, I don't know what is.

 

[doriboni]

It's just a Chinese backdoor like in a lot of Chinese radios.

The AES256 DMRA standard defined by Motorola indicates that the encryption is in OFB mode with a 32-bit initialization vector : IV (the famous MI present in the PI Header).

This MI is bound to change with each transmission, this is the case of Motorola, Hytera and even Anytone (but only since a fairly recent update).

At Baofeng the IV (MI) is always the same, it never changes., do the test with an SDR RTL key and capture the images with dsd-fme or DSD+ (test done on a Baofeng DR-1802U) and the whole Baofeng series is probably the same.

You'll see that the MI of the Pi Header is always the same. This is also the case in other Chinese radio stations. You would have thought it was just a bug, but this is very unlikely because every new Chinese radio that offers AES256 always has the same "bug" (backdoor).

If the IV is always the same, you no longer have the security of AES256 at all. For each key you have a flow that always encrypts the same, it is then a simple Vigenere cipher with a key as long as the message.

Since silence frames are repeated regularly in any conversation because you leave silences between words, with about thirty conversations you get the encryption stream (which is always the same in all conversations with the same AES256 key).

You can then decrypt everything without even knowing the AES256 key.

Of course, some people here will tell me: it's not possible, it's AES256 so it's reliable.

Instead of calling me a troll:

1-Check if the MI of the Pi Header is still the same in your Chinese radio

2-If this is the case, ask ChatGPT about the security of such a system (AES 256 in OFB mode with initialization vector always the same) and you will see that it will confirm what I am telling you.

The advantage of this backdoor is that it remains compatible with Motorola or Hytera radios.

Motorola radio or Hytera receives the MI of Chinese radio and decrypts the conversation. Motorola or Hytera firmware does not send any alerts if the MI is still the same because it is not provided for in the DMRA standard.

So you get the impression that it's as reliable as a Motorola or Hytera radio, but that's not the case at all.

In 2020 someone had already found the backdoor at Anytone:

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.

Note: Don't ask me to prove what I'm saying with a program or example because it's illegal. Check it out for yourself and ask ChatGPT if you don't believe me.

Take out your rtl sdr key and do the test yourself!

 

[Greencloud07]

It's just a Chinese backdoor like in a lot of Chinese radios.

The AES256 DMRA standard defined by Motorola indicates that the encryption is in OFB mode with a 32-bit initialization vector : IV (the famous MI present in the PI Header).

This MI is bound to change with each transmission, this is the case of Motorola, Hytera and even Anytone (but only since a fairly recent update).

At Baofeng the IV (MI) is always the same, it never changes., do the test with an SDR RTL key and capture the images with dsd-fme or DSD+ (test done on a Baofeng DR-1802U) and the whole Baofeng series is probably the same.

You'll see that the MI of the Pi Header is always the same. This is also the case in other Chinese radio stations. You would have thought it was just a bug, but this is very unlikely because every new Chinese radio that offers AES256 always has the same "bug" (backdoor).

If the IV is always the same, you no longer have the security of AES256 at all. For each key you have a flow that always encrypts the same, it is then a simple Vigenere cipher with a key as long as the message.

Since silence frames are repeated regularly in any conversation because you leave silences between words, with about thirty conversations you get the encryption stream (which is always the same in all conversations with the same AES256 key).

You can then decrypt everything without even knowing the AES256 key.

Of course, some people here will tell me: it's not possible, it's AES256 so it's reliable.

Instead of calling me a troll:

1-Check if the MI of the Pi Header is still the same in your Chinese radio

2-If this is the case, ask ChatGPT about the security of such a system (AES 256 in OFB mode with initialization vector always the same) and you will see that it will confirm what I am telling you.

The advantage of this backdoor is that it remains compatible with Motorola or Hytera radios.

Motorola radio or Hytera receives the MI of Chinese radio and decrypts the conversation. Motorola or Hytera firmware does not send any alerts if the MI is still the same because it is not provided for in the DMRA standard.

So you get the impression that it's as reliable as a Motorola or Hytera radio, but that's not the case at all.

In 2020 someone had already found the backdoor at Anytone:

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

Note: Don't ask me to prove what I'm saying with a program or example because it's illegal. Check it out for yourself and ask ChatGPT if you don't believe me.

Take out your rtl sdr key and do the test yourself!

The DM-32 with an AES256 key does not use the same MI/IV like you stated as shown with DSD-FME. The MI changes constantly during a call.

 

[doriboni]

Your test is not performed correctly, you need to display the PI HEADER.

There is only ONE Pi Header per transmission.

Use:

dsd-fme -Z 2>log.txt

and look for the PI header: PI H- in the log.txt file

What you show is the LFSR which is generated from the Pi Header.

Slot 1 DMR PI H- ALG ID: 0x24 KEY ID: 0x0A MI: 0x12345678

 

[Greencloud07]

Your test is not performed correctly, you need to display the PI HEADER.

There is only ONE Pi Header per transmission.

Use:


and look for the PI header: PI H- in the log.txt file

What you show is the LFSR which is generated from the Pi Header.

PI H- MI still looks randomized to me. Then subsequent PI C- MI are seemingly random after the first one.

 

[doriboni]

PI H- MI still looks randomized to me. Then subsequent PI C- MI are seemingly random after the first one.
View attachment 181471View attachment 181472

Ok, there is no backdoor with fixed PI Header in your DM32. Can you give the firmware number?

If other people are doing the same tests, we may be able to check if it's a backdoor, or if the firmware of all Chinese radios was produced by a single manufacturer and the same bug was copied everywhere.

Because someone posted in another topic that the Radtel RT-4D has the backdoor and I myself saw a fixed Pi Header in a DM32 model that I was shown.

Can you do some more tests because visually the PI Header doesn't really look random.
Have the Chinese introduced another backdoor that is less visible than fixed MI?

In both of your tests I see identical parts:

70E55B70 70x55x70
5AF70AF5 5AFxxAF5

Could you do a dozen tests to see if these identical parts are repeated?

The Pi Header should be completely random and not have these kinds of identical parts.

 

[Greencloud07]

My DM-32 is on firmware version DM32.01.02.046. Attached is log.txt from DSD-FME of 12 calls, PI.txt is the output from grep of "PI" , It looks like only the first PI C- part contains the PI H- MI and all subsequent ones are different for the rest of the call. I did this with an RTLSDR, with no antenna to prevent overloading.

This is the same case with a DM-32 on firmware version DM32.01.01.040 (stock firmware).

 

[doriboni]

My DM-32 is on firmware version DM32.01.02.046. Attached is log.txt from DSD-FME of 12 calls, PI.txt is the output from grep of "PI" , It looks like only the first PI C- part contains the PI H- MI and all subsequent ones are different for the rest of the call. I did this with an RTLSDR, with no antenna to prevent overloading.

This is the same case with a DM-32 on firmware version DM32.01.01.040 (stock firmware).

Your DM32 has no backdoor problems, the MI are very different, random and are 32 bits long.

 

[rescuecomm]

Interesting!

 

[doriboni]

PI H- MI still looks randomized to me. Then subsequent PI C- MI are seemingly random after the first one.
View attachment 181471View attachment 181472

Would it be possible for you to test whether the SMS sent from an encrypted channel are encrypted or are not encrypted.

Example of unencrypted 'AAAA' SMS (hexa 0x41 for the letter A):

 

[jakehinds]

Would it be possible for you to test whether the SMS sent from an encrypted channel are encrypted or are not encrypted.

Example of unencrypted 'AAAA' SMS (hexa 0x41 for the letter A):

View attachment 181764

No more follow ups? Shoot....
Do you still maintain your original position that the DM32 does NOT have a randomized PI header? Just getting started on researching all this lol

 

[Greencloud07]

Would it be possible for you to test whether the SMS sent from an encrypted channel are encrypted or are not encrypted.

Example of unencrypted 'AAAA' SMS (hexa 0x41 for the letter A):

View attachment 181764

SMS is not encrypted when sent on a channel with encryption on. Sending DMR APRS or location as a SMS are also not encrypted.

 

[doriboni]

Yes I maintain it, the MI was always the same. Unfortunately I didn't think to note the firmware version. and the friend I had done the tests with, sent the DM32 back to where he had bought it and sent an email of complaint to Baofeng.

It is possible that some radios had the problem and that it was corrected later.

Another friend told me that the baofeng DR-1802U also had this MI problem that doesn't change. He also sent it back to the supplier. But here, I didn't see the MI repaired myself.

No more follow ups?

To have a follow-up, people who have AES256 radios would have to do the MI test and post their results here.

 

[doriboni]

SMS is not encrypted when sent on a channel with encryption on. Sending DMR APRS or location as a SMS are also not encrypted.

OK.
For information, the MD UV380/390 encrypts SMS but still uses 16-bit MI instead of 32-bit.
The Radtel RT-4D does not encrypt SMS.

 

[doriboni]

There's something else to consider: if it was really a backdoor in the DM32, Baofeng maybe it's just hidden.

MI seem random but how many are there in total? I can generate 500 completely random MI and use them and after 500 it goes back to the first MI (whereas in Motorola DMRA mode, there should be 4294967296 different MI before the first one repeats).

It would then be necessary to record the MI produced in the DM32 and check if any MI already produced are repeated at the after a while.

And is it that when you turn off the DM32 and turn it back on, the first MI generated is always the same? if we change the date and the hour, minute, second is it still generating the same MI ?