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.