OP25 OP25 encryption

[MCWKen]

In the past few days, I have noticed some unusual occurrences in OP25. A new encrypted TG (23523) showed up today, and as expected, the interface showed it as encrypted. It cleared, but then an open TG (5303) was set, and showed encrypted.

STDERR shows this starting at 11:28:45. This is not the first time I have seen this behavior. If it were not for the fact I was chasing down information on the new TG, I would have never noticed this.

My command line is thus:
./rx.py --args 'rtl' --gains 'lna:10' -S 2560000 -f 858.0375e6 -T Clinton.tsv -t -2 -w -X -U -v 5 2> stderr.2

Any clues would be appreciated.

Ken
Clinton, IA

 

[MTL_Emergencies]

It may be because the people talking on the talkgroup are activating/deactivating encryption. Did you notice any pattern between encryption and Radio IDs (someone may be transmitting encrypted voice but not all radios have encryption enabled)?

 

[MCWKen]

It may be because the people talking on the talkgroup are activating/deactivating encryption. Did you notice any pattern between encryption and Radio IDs (someone may be transmitting encrypted voice but not all radios have encryption enabled)?

That TG (5303) is an open TG. Radios that use it ( a single agency) are programmed to be open. In the instance in the log, the TG was in use before that time period, and after, and was open.

 

[wgbecks]

It's not uncommon to encounter a mix of clear and encrypted transmissions on the same TGID. I've never seen op25 report that a
TG was encrypted when it was in fact it wasn't. It would be helpful to analyze this by setting the logging verbose to -v 10 and then
allow op25 to run long enough to log (capture) a number of transmissions on TG 5303.

You'll be looking to capture the Header Data Units (HDUs) that will associate TGID's with encryption algo's, clear or encrypted.
Note that OP25 often misses HDU's in that the P25 demodulator can't always sync up fast enough to capture them consistently.
However, you should be able to capture enough of them to make an analysis.

You can watch the logfile in real time with a filter (grep) applied to only print the HDU's. IE: tail -f stderr.2 | grep -i HDU
that will output lines of decoded HDU's that resemble the following example.

03/01/23 23:12:30.700001 [0] NAC 0x79c HDU: ESS: tgid=5027, mfid=0, algid=80, k

In the above line, observe that TGID 5027 was transmitted in the clear (algid=80 in hex). Encrypted transmissions produce HDU's
with ALGID's other than 0x80. IE: 0x81, "DES-OFB, 56 bit key", 0x84, "AES-256-OFB", 0xAA, "Motorola ADP (40 bit RC4)"

Optionally, you could filter the tail sessions to look for the LDU's containing the ESS messages but would have to correlate those
messages with each active TGID in real time. IE: tail -f stderr.2 | grep -i LDU

03/01/23 23:09:03.088621 [0] NAC 0x79c LDU1: LCW: ec=0, pb=0, sf=0, lco=0 : 00 00 04 00 13 a3 3d 2e af
03/01/23 23:09:03.340830 [0] NAC 0x79c LDU2: ESS: algid=80, keyid=0, mi=00 00 00 00 00 00 00 00 00, rs_errs=0

 

[MCWKen]

That is outstanding. Will tend to it when I get home. The encrypted TG's are not used very often, perhaps once a week, which will make it a bit difficult. However, I did keep the entire log just for reference.
Thanks for your help.

 

[boatbod]

In the past few days, I have noticed some unusual occurrences in OP25. A new encrypted TG (23523) showed up today, and as expected, the interface showed it as encrypted. It cleared, but then an open TG (5303) was set, and showed encrypted.

I'd need to check the code but from what I recall, the ESS info persists until reset by the next set of received ESS data. If call1 was encrypted and call2 was tuned but the HDU was missed (a common occurrence), the first frame of call2 is going to appear to be encrypted because the ESS info from call1 will still be in place until overwritten by data from LDU2.

 

[MCWKen]

I'd need to check the code but from what I recall, the ESS info persists until reset by the next set of received ESS data. If call1 was encrypted and call2 was tuned but the HDU was missed (a common occurrence), the first frame of call2 is going to appear to be encrypted because the ESS info from call1 will still be in place until overwritten by data from LDU2.

I was not sure the process, and since it happened so infrequently, it was hard to trace. But, the log showed that TG 5303 did come at the same time as the encrypted TG 23523 and thus, both were 'skiplisted'. So what you say makes perfect sense. Thanks to you both for the help.

 

[boatbod]

I was not sure the process, and since it happened so infrequently, it was hard to trace. But, the log showed that TG 5303 did come at the same time as the encrypted TG 23523 and thus, both were 'skiplisted'. So what you say makes perfect sense. Thanks to you both for the help.

The problem is that op25's c++ library code doesn't track the start and end of calls so it doesn't know when to discard ESS info that has gone stale. Not sure there is a particularly easy solution that wouldn't require python call control to call down to the frame assembler and reset the ESS data.

 

[MCWKen]

The problem is that op25's c++ library code doesn't track the start and end of calls so it doesn't know when to discard ESS info that has gone stale. Not sure there is a particularly easy solution that wouldn't require python call control to call down to the frame assembler and reset the ESS data.

The main reason for my post was, to find out if it was something I was doing wrong. As I said, it happens so infrequently, it really is not that big an issue. Very few TG's here are encrypted with regularity. It just happened to be a new one popped up when this that occurred. When I discover them, they go to the blacklist anyway.


Again, thanks.

 

[boatbod]

The main reason for my post was, to find out if it was something I was doing wrong. As I said, it happens so infrequently, it really is not that big an issue. Very few TG's here are encrypted with regularity. It just happened to be a new one popped up when this that occurred. When I discover them, they go to the blacklist anyway.


Again, thanks.

Under the conditions you describe it should be pretty rare, but it's definitely a quasi-bug/unintended consequence that you exposed.