Anytone Anytone 878 RC4 and AES

[morton1566]

As i can see, the IV (MI parameter in dsd+) in all cases are the same.
It will add extra vulnerability to this implementation. Randomized IV is used to avoid using the same keystream again.
As i can hear in decoded audio the IV properly updated over transmission.
What firmware version your radio running?

Currently using the latest version 1.17.

 

[Astrak]

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.

If I understand the post you linked to correctly, if a radio tunes into an encrypted transmission in progress it won't be able to receive the key ID and won't be able to decrypt the transmission? I tried this by keying up one 878 and transmitting for a few seconds then using another 878 tuning to that transmission and the radio began receiving the transmission.

 

[morton1566]

If I understand the post you linked to correctly, if a radio tunes into an encrypted transmission in progress it won't be able to receive the key ID and won't be able to decrypt the transmission? I tried this by keying up one 878 and transmitting for a few seconds then using another 878 tuning to that transmission and the radio began receiving the transmission.

Interesting test, but we'll need to know what configuration you were using for both radios tested and if the multi-key decrypt option was enabled for this test to be reliable.

It may be possible for the Motorola DMRA standard for encryption to state that radios should only decrypt based on the key referred to in the received key ID for that transmission, but as a manufacturer this could be problematic: what if I don't receive the key ID for whatever reason? (eg. interference, dropped frames)
I could just design my radios to simply not decrypt that whole transmission, but then that reduces the reliability of my radios' abilities to decrypt potentially viable transmissions that have a corrupted key ID field.

So as a manufacturer, I could do something to allow my radios to decrypt properly even if I didn't receive a key ID: typically, when a user programs a channel they would also specify the key ID with the corresponding key to decrypt traffic inbound on that channel. I could use that as a fallback should the transmission I receive not contain a key ID for some reason. Of course, should the manufacturer of the radios use this behaviour, it would invalidate your test since even without the key ID, your radios would still fallback to using the user-specified key ID's key, and hence decrypt the (albeit partial) transmission properly.


I think a better way to test this reliance on a valid key ID would be as per the below:

Radio 1 (transmitter, D878)
- set to channel 1, programmed with key ID 1 and key ID 1 is encryption key of 1.

Radio 2 (receiver, D878)
- has a preprogrammed channel 1, channel programmed with key ID 2 and key ID 2 is encryption key of 1.
- set to startup tuned to another channel (must be different frequency)
- has additional encryption key of 2, but key ID of this encryption key is 1.
- multi-key decrypt option switched off

Radio 1 transmits for a few seconds, then radio 2 is tuned to channel 1.
- take note of the results (radio 2 receives correctly/fails to unmute) as test 1

Next, radio 2 is left on channel 1, and radio 1 begins transmission on channel 1.
- take note of the results (radio 2 receives correctly/fails to unmute) as test 2

So the results would be:

Test 1 result	Test 2 result	Conclusion
Decrypts correctly	Decrypts correctly	Radio decrypts based on received key ID, but if unable to receive key ID or decryption using received key ID is incorrect, will fall back to channel programmed key.
Decrypts correctly	Fails to decrypt/unmute	Radio decrypts based on received key ID first and won't fall back to channel programmed key if decryption is wrong. If unable to receive key ID, radio will fall back to channel programmed key.
Fails to decrypt/unmute	Decrypts correctly	Radio must receive a key ID to decrypt, but can fall back to channel programmed key if it detects wrong decryption key.
Fails to decrypt/unmute	Fails to decrypt/unmute	Radio must receive a key ID to decrypt, and will not fall back to channel programmed key if key is wrong.

This test can be done for any other radio to see what kind of decryption logic it has, but both radio 1 and 2 MUST be the same type/model of radio as different radios' firmware may have differing decryption logic and skew the results.

 

[Astrak]

Multi key and random key were on.

 

[morton1566]

Multi key and random key were on.

So after looking at your test, I thought that I should do similar test(s) of my own to get some experimental results on how the key ID, encryption key and the multi-key setting affects the radio's reactions to transmissions.

From the results, it seems the multi-key decrypt setting affects whether the radio will unmute should it not receive a key ID from a transmission. Note that this experiment is only valid for the D878; other radios that are DMRA AES256 and multi-key-encrypt capable (for example Hytera's higher-end radios) may utilise different logic and would give different results with this experiment. Also, feel free to do more experiments to replicate these results/add on more results.


Here's my test setup:

Programmed encryption keys: key ID 1 has the same key as key ID 2, some additional encryption keys programmed that are completely different up to key ID 50 but the same additional encryption keys used in both radio 1 and 2.

Radio 1 (transmitter, D878):
- Channel 1: programmed with key ID 1, multi-key and random key on
- Channel 2: programmed with key ID 1, multi-key off and random key on
- Channel 3: programmed with key ID 1, multi-key and random key off

Radio 2 (receiver, D878):
- Channel 1: programmed with key ID 2, multi-key and random key off
- Channel 2: programmed with key ID 2, multi-key on and random key off
- Channel 3: programmed with key ID 2, multi-key and random key on
- Channel 4: programmed with key ID 1, multi-key and random key off
- Channel 5: programmed with key ID 1, multi-key on and random key off
- Channel 6: programmed with key ID 1, multi-key and random key on

And the 2 tests:
Test 1 - Radio 2 tuned to another frequency, tuned to Radio 1 transmit frequency 3 seconds after Radio 1 transmission begins
Test 2 - Radio 2 already tuned to Radio 1's transmit frequency from start of Radio 1's transmission

The results are:

Radio 1 channel	Radio 2 channel	Test 1 result	Test 2 result
1	1	Radio receives but doesn't unmute	Radio receives but doesn't unmute
2	1	Radio receives but doesn't unmute	Radio receives but doesn't unmute
3	1	Radio receives but doesn't unmute	Radio receives but doesn't unmute
1	2	Radio unmutes, but decrypts incorrectly (garbled audio)	Radio unmutes, but decrypts incorrectly (garbled audio)
2	2	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
3	2	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
1	3	Radio unmutes, but decrypts incorrectly (garbled audio) / Radio unmutes and decrypts correctly	Radio unmutes, but decrypts incorrectly (garbled audio) / Radio unmutes and decrypts correctly
2	3	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
3	3	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
1	4	Radio receives but doesn't unmute	Radio receives but doesn't unmute
2	4	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
3	4	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
1	5	Radio unmutes, but decrypts incorrectly (garbled audio)	Radio unmutes, but decrypts incorrectly (garbled audio)
2	5	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
3	5	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
1	6	Radio unmutes, but decrypts incorrectly (garbled audio)	Radio unmutes, but decrypts incorrectly (garbled audio)
2	6	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly
3	6	Radio unmutes and decrypts correctly	Radio unmutes and decrypts correctly

 

[Astrak]

I programmed both radios with key ID 17 and 18 with the same keys, then programmed two channels one with multikey on and the other off. I keyed up one radio with key ID 17, the other was off frequency then tuned to the channel with multikey off, the receiving radio did not unmute. The receiving radio did unmute when switched to the channel using multikey. I then transmitted on the receiving radio, the channel on the receiving radio is programmed with key ID 18, using DSD+ I noticed the radio transmitting key ID 17. When left unkeyed for a few seconds it went back to transmitting key ID 18.