Batboard

I've been experimenting with Analog DES-XL encryption on my XTS 5000 and i've noticed a few things:

1) If a MDC Personality is assigned to a personality that is also setup for SECURENET encryption, it will transmit the MDC personalities ID PRE transmission, but will give you no tone, regardless if the PTT ID checkbox is checked or not .

2) If the PTT ID checkbox is checked under the Signaling Tab with MDC, the radio will abide by what's configured in the MDC personality (pre, post, pre with tone, pre with short side tone ), however the radio will transmit the MDC ID TWICE because of the behavior of SECURENET transmissions when a mdc signaling personality is assigned.

3) This extra SECURENET transmission of the MDC ID is done in regular analog mode, then the radio is changed over to analog cipher mode transparently ( without the user taking notice)

4) If you have a sidetone setup to make the user wait and then have PTT ID checked in the personality under signaling, the radio will give you a sidetone before hand during the transmission of the first ID, but while its transmitting the second ID ( which is the same ID anyways), you get no sidetone so the first is kind of useless)

5) There is no way to get a sidetone to transmit with the SECURENET id transmission from what I can tell.

It seems the best way to setup MDC with securenet if you need to decode IDS but not have the ID transmitted twice would to be assign the MDC personality to the conventional personality under signaling, but leave the PTT ID unchecked so 2 IDS don't get transmitted. Then the Associated MDC call lists should decode still, but there still is no way to know when the radio is done txing the ID. Can anyone add to this?

Has MDC / Astro # Aliasing ever been fixed in any version of software for the Astro series ( Astro saber/xts 3000)?

Just thought I'd share my results to save someone some time.

I thought the MDC squawk before a securenet transmission was the key ID, and not the unit ID. Which also explains why there's two squawks before a securenet transmission when PTT-ID is also enabled.

I believe there's a place in the CPS to disable the MDC key ID, if you want to.

That would make sense. I wasn't around when this stuff was being used, so I don't know anything about it. I know the radio automatically tries all the different keys to get a valid stream and if i doesn't then the little red light double flashes....so I don't really know why that would be necessary.

If there is a way to disable that key ID in Astro 25 software since it really isn't needed? What's it for in the first place

compuman81 wrote:That would make sense. I wasn't around when this stuff was being used, so I don't know anything about it. I know the radio automatically tries all the different keys to get a valid stream and if i doesn't then the little red light double flashes....so I don't really know why that would be necessary.

If there is a way to disable that key ID in Astro 25 software since it really isn't needed? What's it for in the first place

In APCO-25, the radio will use the KID and ALGID (algorithm ID) to look up the key in the radio's internal store - if there is no key entered in the slot designated by the KID and ALGID, then the radio will not decode the signal - full stop. Even if you had another KID with the same key, the radio will NOT try any other key to decode.

Now, I've not looked in depth at DES-XL (though the marketing guys keep asking, and keep telling them the same thing - "Make the business case to my boss and have him approve it"), so I cannot say how the protocol works.

compuman81 wrote:...and if i doesn't then the little red light double flashes....so I don't really know why that would be necessary.

the little red light double flashes on any ENC traffic, regardless if the radio has the proper decryption key or not. This assumed the radio is secure (hardware and enabled in the cps) and has "secure LED" turned on (Trunking)

The old Securenet is quite a bit more primitive that P25 DES-OFB or AES-OFB.

I don't think the key ID is embedded in a 12 kbps secure transmission like it is in a P25 transmission. This is why the key ID is transmitted at the beginning with MDC1200. If the radio misses the MDC key ID at the beginning (if it was scanning, for example), it basically has to just decrypt it with the default key, and hope it's the right one... The nice thing about P25 secure transmissions is that the Key ID value is contained in each frame, so the receiving radio gets this info even if it doesn't hear the beginning of the transmission.

It's been quite a while since I used securenet, but I think if you go to the Conventional Personality, Secure II tab, and set the "Key ID" field to "None", that will keep the radio from sending the MDC key ID pre transmission. The actual radio MDC ID can still be sent, depending on it's own setting.

The Key ID is useful to allow a multi-key radio to instantly choose the correct key for decoding a secure transmission, like Wowbagger said. The radios aren't smart enough to know what human voice should sound like, so matching key IDs are the only way for them to know if they should even try to decrypt a secure transmission.

515 wrote:The old Securenet is quite a bit more primitive that P25 DES-OFB or AES-OFB.

The Key ID is useful to allow a multi-key radio to instantly choose the correct key for decoding a secure transmission, like Wowbagger said. The radios aren't smart enough to know what human voice should sound like, so matching key IDs are the only way for them to know if they should even try to decrypt a secure transmission.

There must be some formatting or control message inside the 12kbit/sec stream. It is possible to set a XTS5k to open the speaker only if a correct key is detected, so there must be something the radio can use to decide if a key produces useful output or just noise. It works faster with DES XL than with plain DES. This and the fact that XS is considered less secure than DES proves that there is some sync pattern in XL, stealing some bits and making audio even worse, but extending the range by giving better resync in fading situations.

KEY ID is transmitted via MDC on multi-key capable radios.

Its very short ms duration and shouldn't even be noticed before the radio decodes the incoming key.

You're describing how the radio is supposed to work in a multi-key analog environment.

Some options are mutually exclusive and inclusive..

apco25 wrote:KEY ID is transmitted via MDC on multi-key capable radios.
You're describing how the radio is supposed to work in a multi-key analog environment.

Yes, of course. But still the radio in Securenet operation is able to determine if an incoming coded message is worth decoding, without any MDC, even in a single key setup. I am in the progress of experimenting with some Systems Sabers with multikey capability, to find out more bout it. Nest stage will be some experiments with a logic analyzer to find the pattern inside the stream. Those old fahioned radios allow easier access to the datan than all-DSP XTS5k radios.

Yes, I would be very interested to know what information the "Proper Key Detect" uses to determine if a bit stream is valid or not...