• To anyone looking to acquire commercial radio programming software:

    Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.

    If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.

    To obtain Motorola software see the Sticky in the Motorola forum.

    The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.

    For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).

    This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.

Anytone Anytone 878 RC4 and AES

morton1566

Member
Joined
Apr 26, 2017
Messages
16
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

Member
Joined
Feb 17, 2005
Messages
1,599
Location
Mesa, AZ
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

Member
Joined
Apr 26, 2017
Messages
16
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 resultTest 2 resultConclusion
Decrypts correctlyDecrypts correctlyRadio 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 correctlyFails to decrypt/unmuteRadio 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/unmuteDecrypts correctlyRadio must receive a key ID to decrypt, but can fall back to channel programmed key if it detects wrong decryption key.
Fails to decrypt/unmuteFails to decrypt/unmuteRadio 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.
 

morton1566

Member
Joined
Apr 26, 2017
Messages
16
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 channelRadio 2 channelTest 1 resultTest 2 result
11Radio receives but doesn't unmuteRadio receives but doesn't unmute
21Radio receives but doesn't unmuteRadio receives but doesn't unmute
31Radio receives but doesn't unmuteRadio receives but doesn't unmute
12Radio unmutes, but decrypts incorrectly (garbled audio)Radio unmutes, but decrypts incorrectly (garbled audio)
22Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
32Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
13Radio unmutes, but decrypts incorrectly (garbled audio) / Radio unmutes and decrypts correctlyRadio unmutes, but decrypts incorrectly (garbled audio) / Radio unmutes and decrypts correctly
23Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
33Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
14Radio receives but doesn't unmuteRadio receives but doesn't unmute
24Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
34Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
15Radio unmutes, but decrypts incorrectly (garbled audio)Radio unmutes, but decrypts incorrectly (garbled audio)
25Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
35Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
16Radio unmutes, but decrypts incorrectly (garbled audio)Radio unmutes, but decrypts incorrectly (garbled audio)
26Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
36Radio unmutes and decrypts correctlyRadio unmutes and decrypts correctly
 

Astrak

Member
Joined
Feb 17, 2005
Messages
1,599
Location
Mesa, AZ
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.
 
Top