RFE: Esk Key for EDCAS Systems

[mike_webb59]

Uniden will roll out firmware updates for many of their trunktracking scanners over the next few months.

The firmware update will include ESK Support for EDACS Systems. It will require that the key be programmed as a decimal value. It will also require that the user knows this value.

I submit that a particular EDCAS Systems' ESK key is no longer a proprietary value:
1) It is a static offset based on the ASCII specification of 0-255
2) It is not an encryption algorithm or license-restricted software-component.
3) It is currently acquired by commercially available scanners and scanning software.

Current GRE scanners automatically decode ESK. ETrunker software will acquire and display the ESK Key in a hex value.

This is is an RFE to include (and allow for the free exchange of) ESK Key values in the RR database for appropriate systems.

Thanks, Mike

 

[andrewccm]

I agree.

Anyone have D/FW Airports yet?

 

[hiegtx]

I agree.

Anyone have D/FW Airports yet?

I'm taking both the 396 & the 500 to work tomorrow (in Coppell). If I don't get slammed with orders. I'll experiment with it & see what comes up. I'm getting hits on the 500 from work, so signal reception is no issue at all.

 

[SCPD]

I applaud everyone for being proactive. However, logging ESK masks is not necessary. Allow me to explain why.

For the most part, ESK does not involve the control channel. The purpose behind ESK is to prevent someone from purchasing an EDACS radio from eBay, downloading a bootleg copy of Programmer and programming the radio to operate on someone else's trunked network. Encryption occurs between the programming software, the radio, and a smart card - not over the air. New radios have this security feature.

If you acquire a radio and try to program it for a different system (that is ESK enabled), you're out of luck.

The problem is there are still used/surplus models available that could be easily programmed to access an EDACS system. That brings us to the EDACS control channel. Both new and old radios understand the 28 bit codewords that make up the control channel messaging. MA/COM needed a way to prevent the older radios from accessing the control channel. Instead of inventing a new control channel - MA/COM flipped two bits of each codeword. This was just enough to break compatibility with the older radios. No need to issue different ESK "keys". For this trick to work only three bits are worth flipping so out of 8 possibilities - they chose one. After two years of Unitrunker providing auto-ESK detection, I've only seen one mask value in use.

The bottom line for MA/COM customers willing to purchase radios with ESK firmware and the associated programming software (I think I saw a $15k price tag somewhere for the software) - is - they can deploy a trunked system reasonably safe from pirate or rogue users. Take notice: this prevents access (eg. transmitting on the system). It does nothing to prevent monitoring (it just took us a few years to realize this).

Knowing whether a system is ESK capable is useful but there is no need to database the ESK mask for every system. It is constant.

 

[ElroyJetson]

So when do I get to download radio code for my 7100IP portables that automatically handles ESK so I don't have to buy, barter, and beg my way to getting the ESK key loaded into my radio?


Elroy

 

[blantonl]

I believe from a control channel decoding perspective (decoding the command words from the data stream) ESK is just the XOR of the command words with 0A.

And the fact that we figured that out is great for scanner listeners.

HOWEVER, I believe that "real" EDACS radios and infrastructure with ESK features requires a unique key and code to both decode the control channel and participate in the network. That means there are components of the ESK control channel that we don't know about yet - those components actually broadcasting the ESK unqiue key for that system. Non one has figured that out yet.

If this wasn't the case, what would prevent a person with their own ESK smartcard and ESK enabled radios from joining *any* ESK network? Nothing. My understanding is that a smartcard issued to a agency is tied to that system, and a radio not programmed with the data on that card can't participate in the network.

I believe that the XOR of the command words with 0A does nothing but indentify the control channel as a ESK control channel. The radios and infrastructure has a 2nd layer of data and information that ties everything all together into a unique ESK network.

 

[wa8pyr]

I believe from a control channel decoding perspective (decoding the command words from the data stream) ESK is just the XOR of the command words with 0A.

And the fact that we figured that out is great for scanner listeners.

HOWEVER, I believe that "real" EDACS radios and infrastructure with ESK features requires a unique key and code to both decode the control channel and participate in the network. That means there are components of the ESK control channel that we don't know about yet - those components actually broadcasting the ESK unqiue key for that system. Non one has figured that out yet.

And if that unique key value would enable an unauthorized person to hack an EDACS radio onto a system, I would really have a problem with posting it here. Such a thing could cause major difficulties, not only for the hacked agency but also for us here on RR. I think we should start treading very, very carefully on this subject; flipping a command word to allow a scanner to track the system is one thing, but a unique key value that could allow hacking into the system is another thing entirely.

 

[blantonl]

And if that unique key value would enable an unauthorized person to hack an EDACS radio onto a system, I would really have a problem with posting it here.

At this time it wouldn't... everything is smartcard based, and there is no process to either retrieve the value or store it on a card in place today.

 

[mike_webb59]

HOWEVER, I believe that "real" EDACS radios and infrastructure with ESK features requires a unique key and code to both decode the control channel and participate in the network. That means there are components of the ESK control channel that we don't know about yet - those components actually broadcasting the ESK unqiue key for that system. Non one has figured that out yet.

Can I then ask you to review the new Uniden Feature and determine if the "set ESK" value required to track ESK-enabled EDACS Systems can be distributed here at RR.

Thanks, Mike

 

[blantonl]

Can I then ask you to review the new Uniden Feature and determine if the "set ESK" value required to track ESK-enabled EDACS Systems can be distributed here at RR.

Thanks, Mike

Mike, the set ESK value will be the same for every system in the country. We've never seen an ESK system with command words that are XOR'd with anything other than 0A.

Again, there is a difference between what the ESK KEY value is, and what the command words are XOR'd with. We have no way of knowing or decoding the ESK Key value at this time - we only know that the command words are XOR'd with 0A. Uniden is probably making a false assumption that the XOR value can change. It doesn't.

 

[mike_webb59]

Mike, the set ESK value will be the same for every system in the country. We've never seen an ESK system with command words that are XOR'd with anything other than 0A.

Again, there is a difference between what the ESK KEY value is, and what the command words are XOR'd with. We have no way of knowing or decoding the ESK Key value at this time - we only know that the command words are XOR'd with 0A. Uniden is probably making a false assumption that the XOR value can change. It doesn't.

Oh, I see .....

I "set" the Bexar County EDACS ESK key to this AO "default" value and I can receive TGID transmissions from SAPD Blue and SAPD Topperwein. If I deviate from that "default" value I cannot lock in the system.

What you are saying is that this value (A0) is the same for all ESK enabled systems, yes? If so, then does the decimal version of this hex value need posting, or should I post an RFE to Uniden to add it in their documentation, or can I make a sticky on the Uniden forum.

PS: ESK support will be available for most Uniden models by years' end so this question may resurface again.



Thanks again, Mike

 

[Thayne]

Correct me if I'm wrong, but didn't ESK come out before RPM? I am hoping there may be a way to "turn on" ESK in older radios that have the feature installed but not enabled; besides buying software that costs over 10 grand. There are a lot of them around just gathering dust. They do work way better than scanners for monitoring only EDACS systems.

 

[SCPD]

I "set" the Bexar County EDACS ESK key to this AO "default" value

Stop right there! This value is a mask, not a key. The mask is separate from - and not directly related to - the key you would need to program a two-way radio onto an ESK system. You need the mask to monitor the system; you don't need the actual key.

(Encrypted voice channels are a separate subject)

What you are saying is that this value (A0) is the same for all ESK enabled systems, yes?

That is what we're both saying.

If so, then does the decimal version of this hex value need posting, or should I post an RFE to Uniden to add it in their documentation, or can I make a sticky on the Uniden forum.

Surely by now Uniden has figured this out.

There are two mask values of interest - a mask of zero (for non-ESK systems) and a 4 bit mask of "A" (for ESK systems). Applying the ESK mask to bits 24, 25, 26, and 27 of the received 28 bit codeword as an exclusive OR operation has the effect of flipping two bits. Applying the non-ESK mask of zero leaves the bits unchanged. The result can be used to decode the control channel messages.

If the yet-to-be-seen Unidens require a value of "A0" to operate correctly - it just means their firmware expects an 8 bit value rather than a four bit value ("0A" as Lindsay writes).

Again - there will only be two values of interest here. Uniden could just as easily display "ESK = On" and "ESK = Off" to avoid confusing everyone.

 

[RayAir]

And if that unique key value would enable an unauthorized person to hack an EDACS radio onto a system, I would really have a problem with posting it here. Such a thing could cause major difficulties, not only for the hacked agency but also for us here on RR. I think we should start treading very, very carefully on this subject; flipping a command word to allow a scanner to track the system is one thing, but a unique key value that could allow hacking into the system is another thing entirely.

Why have a problem with it? Most anyone here could already hack into most radio systems if they wanted to. But we don't, because it's not our purpose.

 

[ElroyJetson]

Legally speaking, information of this type is not a legal issue if the information was deduced by means OTHER than reverse engineering or decompiling source code or software in violation of copyright restrictions. If it was obtained via open source investigative procedures, then there's nothing that M/A-Com can do about it. The airwaves are free to monitor with the exception of cellular in specific
named band ranges.


Elroy

 

[blantonl]

Again - there will only be two values of interest here. Uniden could just as easily display "ESK = On" and "ESK = Off" to avoid confusing everyone.

Folks - I want everyone to read the above. Read it again and again... then read it again.... now that you have read it three times, and hopefully it has sunk in, we should realize the following:

1. There are no unique valued for the masking value that we need to track.
2. There are no values that a "hacker" could use to hack a system.

That's it folks..... :roll:

 

[DonS]

I'll go a little further than Rick and Lindsay...

I would suggest that there's no need for a scanner to take any user input, at all. After all, it's only 3 lines of code to determine that ESK is in use, deduce the mask value, and apply it to every received message.

From a scanner user's point of view: Any "ESK" display should be purely informational, with no need for the user to enter/change anything on the scanner (presuming the scanner supports ESK in the first place). On RR, the only thing that's necessary is an indication that the system uses ESK (like we have now), to be used only to determine if a particular scanner can track the system.

 

[UPMan]

This thread is based on very old news (the initial beta of the ESK feature). The scanner will not require the ESK value to be entered. It will automatically detect if ESK is being used and will automagically track the ESK system with no user intervention.

I'd suggest that this thread be closed, locked, and buried.