EDACS Provoice

[SCPD]

long-winded reply

Hi Joe;

Well, it all comes down to interpretation.

Uh, oh ... someone playing devil's advocate ... cool! To other folks tuning in, we're just hashing stuff out in the open for the benefit of all.

Would the FCC consider the key to be a form of encryption (regardless of how it was intended)?

This is more of an issue for a federal court than the FCC. Moreover, it's an interpretation that cuts both ways. If Tyco (isn't that who sells EDACS these days?) were to market ESK as encryption they would be opening themselves up to legal problems for false advertisement.

Would you trust a manufacturer than claimed that an eight bit exlusive-OR qualified as encryption?

I'll use this as an example: Many manufacturers elected to not include I-call because its function was too closely related to a private phone call and they didn't want to violate any FCC Cellular-based rules. (is there any expectation of privacy using an I-call?)

The key here (pun intented) in your arguement is "many manufacturers" - many but not all. Clearly not all mfgrs feel this way. Uniden allows I-calls on some radios (I think the '780XLT will do so) but not others ('245XLT). Some mfgrs market both scanners and 2-way equipment so this may be driven by marketing rather than concern over some FCC ban. Some 2-way folks consider us scanner listeners as a nuisance. They'd be sensitive to purchasing equipment from the same company that makes it easy for the rest of us to listen.

Note that nearly all scanners can monitor cordless phones so I don't see this specific issue as a big deal to them.

Regardless of how simple the 'encryption', the origin or reasoning behind its implimentation, or how many possible combinations (keys) there are, it could be considered to be encrypted or coded, and protected under the encryption laws.

Encryption and encoding are two separate things. To transfer information, you must encode it - no way around that. If encoding were the same as encryption, then this entire message board - and every other form of digital media is "encrypted".

LTR uses a code to separate two systems (0 and 1), but it is part of the same code and does not alter the datastream at all (beyond that single bit).

Cool ... good analogy to ESK.

As I understand it (and I could be wrong), ESK actually changes the code (datastream) by using it as a key to decode the stream. This is a big difference.

To decode any EDACS control channel you must have an 8 bit "key" (and it might actually by only 4 bits - we're still figuring this stuff out). If you set the key value to zero, you get a control channel that Tyco markets as plain EDACS. If you set the key value to 0xA0, then you get a control channel that has been marketed as ESK. The point here is if any one of these keys constitutes encryption, then all key combinations are a form of encryption. If that is the case, then even plain, non ESK EDACS is encrypted.

The ESK seems to much more closely resemble encryption - where you need a key to put the datastream back in the base form to recover the voice data (or CC data).

Yeah, it's CC data we're talking about here. Changing the encoding can create the appearance of encryption so this perception is understandable.

Again, whether there are 16 zillion, or two possible key combinations is only a difference of magnitude. Where do you draw the line? (The FCC draws it as anything beyond a standard stream - no keys needed - like P-25)

I'm not sure how this falls under FCC interpretion. I think the USC 2511 (is that Title 9?) definition is a transmission scheme with parameters "not readily available to the public." I'll defer to David Stark and others (who give excellent commentary on subjects like this BTW) but I will go out on a limb and suggest that publishing how something like ESK works makes that knowledge public (though not public domain - that's a different animal).

Of course, should M/A-Com elect to authorize a manufacturer to use the code, and decrypt their control channel, this would all be a moot point. Now, who really can authorize the decryption? The manufacturer, or does it have to come from the *licensee*!

Using a combination lock as an analogy, the lock owner would carry that right (and burden). Does the fact that you use Schlage as your brand of door locks grant the Schlage corporation access to your home? [ Sorry, I couldn't resist. ]

Voice inversion is a very simple scrambling method, and an 8-year-old can crack it. Still, it is illegal to do. It's amazing that one manufacturer can legaly sell a voice inversion option for their scanners. (or maybe it is illegal to sell that option in the USA)

This is a great example of legislative stupidity. If someone wants to make their analog voice comms *slightly* more secure, they can use speech inversion or SI. But wait, the receiving half of the SI system could be used to "intercept" someone else's SI communications. It's a catch-22 that should never have existed. The law actually results in less privacy instead of allowing us to pursue more (and worse, makes some folks think their SI comms are secure).

Not trying to debate the issue - just bringing up some alternative points of view.

Well, this is a forum, after all - and you've brought up some great points.

After all, the FCC's 'opinion' is the only one that matters.

Again, I don't think it's the FCC. They aren't going to refuse to issue a type acceptance for some piece of gear over I-calls or ESK - IMHO. There are much, much bigger issues or concerns for a manufacturer with IP law - mostly patents and trade secrets. I think that's the real reason here.

( and thanks for the discussion )

Regards,
Rick

 

[Thayne]

Good points all.
I guess I just bemoan the fact that we as a society are so driven by the profit motive; When I was a kid, we had time and the desire to experiment with things like electronics instead of drugs and getting more money. Usually our moms were home all day.
Now everybody in the family has to work to pay for all the toys that we want. When the toys crap out, we just trash it and buy a newer one. You are pushed into it, because of the improvements incrementally fed to us.
I was going to try to fix a 1998 TV that died. Fat chance--The whole circuitry was on one board with surface mount on both sides, stuff that I could barely see, let alone identify. Besides, there is nowhere left in town to buy parts anyway.

(Radio Shacks grey drawer selection doesn't cut it)

Oh Well, enough of the ranting of this old fart

 

[Voyager]

Re: long-winded reply

Hi Joe;

Uh, oh ... someone playing devil's advocate ... cool! To other folks tuning in, we're just hashing stuff out in the open for the benefit of all.

[/B]

And enjoying it all... (until I hit REFRESH just before I sent my first reply!) :-( Now I have to retype the entire thing! !%#$^%

This is more of an issue for a federal court than the FCC. Moreover, it's an interpretation that cuts both ways. If Tyco (isn't that who sells EDACS these days?) were to market ESK as encryption they would be opening themselves up to legal problems for false advertisement.

Would you trust a manufacturer than claimed that an eight bit exlusive-OR qualified as encryption?

No, but isn't the issue whether it is a form of encryption vs the level of encryption (the number of keys)?

Many people have referred to it as encrypting the CC. I just assumed they were correct about that. (Yes, I know what that means...)

The key here (pun intented) in your arguement is "many manufacturers" - many but not all. Clearly not all mfgrs feel this way. Uniden allows I-calls on some radios (I think the '780XLT will do so) but not others ('245XLT).

Yes, some later decided to include I-calls. Some have not, including Trunker. ;->

On that subject, why are I-calls no longer supported on 9600 systems? Is there a technical reason for it?

Note that nearly all scanners can monitor cordless phones so I don't see this specific issue as a big deal to them.

That's a global-scale pandora's box, so I won't comment too much on it. They only excluded the Cell freqs since the FCC 'asked' them to... you know... asked... "do it or else!"

Actually, many (most) of the cordless stuff is now digital and (I really hate to say it...) unmonitorable.

Encryption and encoding are two separate things. To transfer information, you must encode it - no way around that. If encoding were the same as encryption, then this entire message board - and every other form of digital media is "encrypted".

True, but encryption is legal to decode on the internet - using PGP (I think that's it) is one way. It's encrypted, but the key is made available. I don't believe this board uses encryption at all - it's using the standard communications protocols.

Cool ... good analogy to ESK.

Really? Perhaps ESK doesn't work as I thought it does. I was under the impression that the ESK changed the entire datastream, and you needed the ESK key to reassemble the stream into a standard EDACS stream.

To decode any EDACS control channel you must have an 8 bit "key" (and it might actually by only 4 bits - we're still figuring this stuff out). If you set the key value to zero, you get a control channel that Tyco markets as plain EDACS. If you set the key value to 0xA0, then you get a control channel that has been marketed as ESK. The point here is if any one of these keys constitutes encryption, then all key combinations are a form of encryption. If that is the case, then even plain, non ESK EDACS is encrypted.

Not if the key 'value' is zero. If you change a P-25 datastream by using the key 0xA0, you would need to know what key was used to change the stream in order to put it back to standard. A key value of 0x00 would not change the stream at all, so it's still a standard (unencrypted) P-25 datastream.

From what you are saying, the ESK is nothing more than a system ID that is sent along with a standard datastream. If that is the case, it changes the issue entirely, and the ESK is not a key at all in the conventional use of the word in communications. If it's just a system ID consisting of 4 (or 8) bytes, why can't you simply ignore those 4 (or 8) bytes and process the rest of the stream as you would a standard EDACS datastream?

I'm not sure how this falls under FCC interpretion. I think the USC 2511 (is that Title 9?) definition is a transmission scheme with parameters "not readily available to the public." I'll defer to David Stark and others (who give excellent commentary on subjects like this BTW) but I will go out on a limb and suggest that publishing how something like ESK works makes that knowledge public (though not public domain - that's a different animal).

So, you're saying that if someone found a way to decrypt a DES transmission (without the key), and made that public knowledge, DES could no longer be considered encryption?

Using a combination lock as an analogy, the lock owner would carry that right (and burden). Does the fact that you use Schlage as your brand of door locks grant the Schlage corporation access to your home? [ Sorry, I couldn't resist. ]

No problem. I figured it would be up to the licensee to allow access. It appears this may be a moot point anyway if the ESK works more like a system ID.

Well, this is a forum, after all - and you've brought up some great points.

Thank you. And I'm enjoying the conversation very much. I especially look forward to your reply, as it may change how many people see the ESK.

Again, I don't think it's the FCC. They aren't going to refuse to issue a type acceptance for some piece of gear over I-calls or ESK - IMHO. There are much, much bigger issues or concerns for a manufacturer with IP law - mostly patents and trade secrets. I think that's the real reason here.

If TYCO has developed the ESK as a system ID type scheme only, then I would agree - they really wouldn't care if scanner manufacturers decide to use it for the same purpose. After all, decoding an EDACS CC is much more of an issue.

Of course, this brings up yet another off-topic issue. I have to program the system ID in user radios so their radios don't respond to other systems that may happen to use the same frequency for a CC. Why is it that scanners did not incorporate this for the same reason? If I travel to an adjacent county, and my scanner picks up a distant CC, there is nothing to keep it from responding to that CC and giving me bogus TGs/transmissions.

The PRO-96 displays the system ID, but does not seem to use it. Is this part of the patent circumvision?

( and thanks for the discussion )

Regards,
Rick

And thank you very much as well. I do have one more off-topic question and you may know the answer: Why is it that 3600 systems have a 4-byte system ID, but 9600 systems only have a 3-byte system ID?

Thanks again,
Joe M.

 

[SCPD]

Re: Re: long-winded reply

And enjoying it all... (until I hit REFRESH just before I sent my first reply!) :-( Now I have to retype the entire thing! !%#$^%

I hate it when that happens!

No, but isn't the issue whether it is a form of encryption vs the level of encryption (the number of keys)?

YES - I'm asserting that ESK is not encryption.

On that subject, why are I-calls no longer supported on 9600 systems? Is there a technical reason for it?

Huh? I-calls and phone patch are very much supported by Project 25. As for why a particular radio omits this option is up to the mfgr.

Actually, many (most) of the cordless stuff is now digital and (I really hate to say it...) unmonitorable.

Coming soon ... the DECT decoder! (just kidding)

True, but encryption is legal to decode on the internet - using PGP (I think that's it) is one way. It's encrypted, but the key is made available. I don't believe this board uses encryption at all - it's using the standard communications protocols.

It's semantics - you could (well, not you but someone) argue that a URL is a "key". Without the URL, you can't "decode" the webpage.

Perhaps ESK doesn't work as I thought it does. I was under the impression that the ESK changed the entire datastream, and you needed the ESK key to reassemble the stream into a standard EDACS stream.

No - supporting it required all of five lines of code in ETrunk. Four of those lines were for the purpose of reading the ESK setting.

Not if the key 'value' is zero. If you change a P-25 datastream by using the key 0xA0, you would need to know what key was used to change the stream in order to put it back to standard. A key value of 0x00 would not change the stream at all, so it's still a standard (unencrypted) P-25 datastream.

First, the designation that "0x00" is "standard" is arbitrary - particularly when the binary formula to crunch out an EDACS data frame involves iterative XOR operations. Second, ESK is EDACS, not P25.

From what you are saying, the ESK is nothing more than a system ID that is sent along with a standard datastream.

Actually, the ESK value may very well be sent - just not with every frame.

If it's just a system ID consisting of 4 (or 8) bytes, why can't you simply ignore those 4 (or 8) bytes and process the rest of the stream as you would a standard EDACS datastream?

It's 4 or 8 BITS, not bytes. There are a set of commands sent over the control channel - the meaning of these messages changes with different ESK values.

So, you're saying that if someone found a way to decrypt a DES transmission (without the key), and made that public knowledge, DES could no longer be considered encryption?

Yes - traditional "cracking" efforts where a whole range of key values is tried still requires the receiving end to pick a key. Years ago a german mfgr of secure packet radio communications delivered a secure system to a now defunct government. At the request of a certain other government entity, the mfgr modified the equipment to include some extra data in the handshake between radio data terminals. It turns out this extra data was the de-crypting key. This back door was used by one government to monitor the communications of another. In this case, the encryption was rendered useless - though not readily apparent to the equipment operators.

Why is it that scanners did not incorporate this for the same reason?

The system ID is more important in the programming of a 2 way radio than a scanner. You don't want some other systems' radios erroneously roaming onto your network. Each EDACS operator can choose their own system id. One way for an EDACS operator to cope with a distant neighbor is ESK.

Also, there are lots of bugs, discrepancies, and overlooked options for trunk capable scanners. Consider how Type I vs. Type II Motorola IDs are handled in the various Uniden models

The PRO-96 displays the system ID, but does not seem to use it. Is this part of the patent circumvision?

I can't speak for GRE (or Uniden). I don't think there is any patent "circumvention" going on.

-rick

 

[SCPD]

originally posted by Voyager:
Why is it that 3600 systems have a 4-byte system ID, but 9600 systems only have a 3-byte system ID?

System IDs are displayed using hexadecimal digits. That's digits 0 through 9 plus "digits" A through F to represent the values 10 through 15. Each digit represents four bits. It's a 4 digit system ID for Motorola (that's 4 digits times 4 bits each or 16 bits - two bytes). It's a 3 digit system ID for Project 25 (3 digits times 4 bits each or 12 bits total - one and a half bytes).

Why only 3 digits for Project 25? *shrug* My guess is the designers didn't want something that was to be broadcast repeatedly to take up too much space. Every design is a compromise. Project 25 offers 16 bit talkgroups and 24 bit radio ids. Motorola Type II systems offer 12 bit talkgroups (the 4 "status bits" don't count) and 16 bit radio ids.

 

[blantonl]

A couple points here:

As I look at the EDACS command word structure, and the differences between and ESK control channel and a standard EDACS control channel, it is painfully obviously that there is no encryption involved.

As it has been pointed out in this thread, the primary purpose of the ESK control channel is to differeciate between non-ESK networks and ESK networks. Radios programmed onto an ESK network must be programmed with a smartcard, so that's what makes an ESK network more secure. The "structure" of the control channel hasn't changed a single bit. I can envision the process that MA/COM followed when developing this.

Executive -> "Mr Engineer, we need to come up with a more secure EDACS network. Develop it please."
Engineer -> "Yes sir. I'll just apply a mask to the existing command word structure, and now we have a new control channel"
Executive -> "How is it more secure Mr engineer?"
Engineer -> "Well Mr. Executive, for any radio to operate on this new ESK network, it will have to be programmed with software that requires a smartcard for operation."
Executive -> "Outstanding Mr. Engineer, we'll make millions"
Engineer -> "Can I get that raise I asked for?"
Executive -> "No way buddy, I'm still paying off that shower curtain for the New York apartment..."

That's probably how it went.

I look at it as simply a new version of the EDACS control channel.

There isn't any evidence that any system ID or unique system identification is transmitted or involved between the two control channels. The only common bridge between the two are some new command words that tell an EDACS radio to either "look" for a regular control channel, or an ESK control channel. This allows the system operators to dynamically change from a regular control channel to an ESK control channel - with the switch being transparent to the end users. And it also provides backwards compatability so networks can upgrade radios to ESK code, and then flip the switch once everyone is flashed up.

...and, on another note, I've heard reports that the DFW Airport has gone to ESK as well. Thus, the trend has begun! Two EDACS control channels. A quite frankly, I don't see any reason why scanner manufacturers won't clear this hurdle soon.

 

[SCPD]

I was going to try to fix a 1998 TV that died. Fat chance--The whole circuitry was on one board with surface mount on both sides, stuff that I could barely see, let alone identify. Besides, there is nowhere left in town to buy parts anyway.

Maybe not ...

http://www.73.com/a/0142.shtml

-rick

 

[Thayne]

Thanks, Rick. I have bookmarked that site. I sent that TV chassis to landfill heaven already though. The owner of the last place in Denver to get RCA manuals & parts has died.

More importantly, I am enjoying the postings in this thread; very interesting stuff. Some of these young guys amaze me with their understanding of theories.

 

[Thayne]

I have been doing a lot of research on DSP's and Vocoders, etc.
the last few days. (I am sure that some out there already know this stuff, so feel free to correct me or voice your opinions on the following)

ProVoice uses the IMBE Vocoder developed by DVSI, as does APCO 25. It is not exactly the same, but VERY close.
Also, DVSI has just come out with an even better scheme that makes it possible to compress apco 25 even further to squeeze more info into the bandwidth(Or increase the speech quality if needed)

OEM Provoice radios use a dedicated dsp chip, with software code from DVSI.
I am pretty sure that the PRO-96 uses a 16 bit processor rather than a dedicated DSP chip. (Comments??)
DVSI probably needed to be paid for the software license. The PRO-96 could probably do ProVoice with the correct Vocoder software, and making it also decode the EDACS stream that tells the radio the type of transmission. (I-call; Digital; Emergency; etc.
Of course, how could they make any money by doing that??

 

[rdale]

ProVoice is not an open standard, so wouldn't they have to 1) get authorization from M/A and 2) pay them?

- Rob

 

[Guest]

ProVoice is not an open standard, so wouldn't they have to 1) get authorization from M/A and 2) pay them?

- Rob

Was the Motorola control channel an open standard back when the first generation TrunkTracker came out?

How about the EDACS control channel when the TrunkTracker II came out?

We can learn about what will happen in the future by looking at what has happened in the past.

 

[rdale]

Could that be apples & oranges? I'm no legal guy at all - just throwing things out... Since everything HAS to go through DVSI in the first place, I could see that being a sticking point. In the other two examples, didn't they reverse-engineer the control channel using 'off-the-shelf' technology?

- Rob

 

[pro92b]

I am pretty sure that the PRO-96 uses a 16 bit processor rather than a dedicated DSP chip.

The PRO-96 uses a TLV320AIC13CDBT codec and a TMS320VC5409APGE12 DSP both made by Texas Instruments.

 

[scan-pa]

MaxTracker said:

I am thinking, Uniden will devolope a ProVoice friendly scanner soon, they already were first to do Open Sky.

When did Uniden developed an Open Sky scanner? or is this an exclusive radio for M/A Com customers? Just asking....

Never going to Happen, the 2 strong selling points for M/A Com is that No Scanner will ever monitor these 2 types of systems. But M/A Com did say they will sell a Monitor unit that will only scan the TG selected by the Programmers... And they can be disabled by the Dispatcher at any time. Some type of coded signal that can enable or disable any and all monitor units..... price reported to be 1000.000 bucks per unit for the PSP Media Monitor units for there new Open Sky system.

 

[scan-pa]

ProVoice is not an open standard, so wouldn't they have to 1) get authorization from M/A and 2) pay them?

- Rob

Yes! Rob, is totaly correct on this point.


This is now the POST 9-11 era! Police Dept. will press for systems that can not be monitored or accessed

 

[kikito]

This is now the POST 9-11 era! Police Dept. will press for systems that can not be monitored or accessed

Yeah, even though the terrorist could care less about being able to listen to Police... As long as they could get classes on how to fly a plane which is "harmless" :wink: :lol:

 

[ah7e]

Re: Provoice revisited

I have verified that GRE scanners will show Provoice TG's; My 785D just ignores them completely.

I have a RS Pro-92, firmware v1.00. Honolulu PD uses mixed mode analog/ProVoice for communications. It will show all groups (including PV) that are active, but like what others said, the PV audio cannot be decoded.

Other scanners that I own simply ignores the digital group. It's pointless to listen to static.

I verified those dec talkgroup IDs during a trip to the City EOC communications center.

 

[Thayne]

Thanks for the reply.
For my purpose, (not spending lots of money on a new scanner every year), I have been financially helping a 18 year old computer whiz from Romania that has made more progress in decoding ProVoice than I could in a million years. We also have been analyzing the APCO-25 CC Data.

I did buy a new scope that cost a LOT more than a scanner, but I wanted a better one anyway.

Like somebody on here said, it couldn't be put on the market though without pissing off the manufacturers, who might bury me near area 51 with my ass out of the ground so Ashcroft could kick it as he goes by.

 

[wwhitby]

Never going to Happen, the 2 strong selling points for M/A Com is that No Scanner will ever monitor these 2 types of systems.

I remember back in 1996 when I first starting learning about trunked systems and collecting data, I would ask the question "would scanners be developed that could follow trunked systems." I was repeatedly told that there would never be a scanner that could follow Motorola trunked systems, since Motorola would sue anyone who developed one. After the BC235 came out, I was told that Ericsson would never allow anyone to develop a scanner capable of following an EDACS system, since EDACS was propriatary. After the BC245 came out, the big focus was on P25, and I was told that, yes it could be done since its an open standard, but probably wouldn't since a scanner would cost well over $1000 each (actually, I remember that one fella said $2000.) Now we can buy them for less than $500.

I've learned never to say never, and hope for the future.

Write to GRE and Uniden, and write frequently. Let them know what products or features you want to see.

Warren[/quote]

 

[N_Jay]

Never going to Happen, the 2 strong selling points for M/A Com is that No Scanner will ever monitor these 2 types of systems.

I remember back in 1996 when I first starting learning about trunked systems and collecting data, I would ask the question "would scanners be developed that could follow trunked systems." . . . .
I've learned never to say never, and hope for the future.

. . .

[/quote]

Maybe it was "who" you were asking? :twisted: