Security can a key aspect of public-safety communications, but Project 25 (P25) system managers should establish policies to help ensure that encryption is used only when necessary, P25 network veterans said during a best-practices workshop in Washington, D.C., sponsored by Tait Communications. While encrypted communications are vital for some specialized personnel—for example, members of SWAT teams, bomb squads and narcotics operations—it is not advisable to use encryption for all public-safety communications, according to Craig Jorgensen, former president of the P25 steering committee. “Encryption was never intended to be a ubiquitous tool that everybody has; if everybody’s got it, there no longer is the security element that you want,” Jorgensen said. “Encryption was intended for high-security risks, not just day-to-day traffic.
I will try to clear up some assumptions about P25 and encryption. Form the start of the use of radios in the public safety it has been possible (and widely accomplished) to monitor the radios. The threat from all MEJI type issues has always been present but has been shown to be historically low. All our radios are certified to the APCO Project 25 (P25) digital two-way radio standard, and offer guaranteed interoperability with other agencies and organizations using P25.
The cost of encryption is not only the economic costs but the cost of the spectrum that you’re using to perform the encryption, and there’s still a minor degradation of voice quality in encryption. “So, encryption shouldn’t be dealt with as an option, like a green light or a blue light. You should look at why I need it, how much am I willing to pay for it, and who really needs it.” Another issue with encryption is that it is not always possible to coordinate the security feature with other jurisdictions that may provide help during an emergency, according to Allen Holder, director of Lincoln County 911 Center in West Virginia. “If you encrypt too much, you may make your network so secure that you lose the benefit of interoperability,” Holder said.
This sentiment was echoed by several participants, with some noting that they have policies against using encryption on mutual-aid channels. There was a general consensus that public-works and public-service employees do not need encryption capabilities on their radios, but encryption usage for non-specialized public-safety organizations varied significantly between the participants. “I put encryption in all my equipment and components in the statewide system, because I was told that everything had to be encrypted in 1999,” said Paul Leary, chief of communications for the state of New Hampshire.
“Fourteen years later, I have yet to have to use an encrypted channel in my department. “We put too much into the idea of encryption. On the data side, we know we’re going to have to have that encrypted—they want us to have that. With voice, my biggest fear is with interoperability and people getting into trunked systems without a gateway set up, or they don’t have the agreed interoperability channels loaded into their radios.” Flexibility is necessary, according to Mike Ward of Beaufort County Communications in South Carolina. “In my opinion, it really depends on how the agency wants to operate and at what level,” Ward said. “Our sheriff said, ‘All of my stuff is going to be encrypted; that’s how it’s going to be,’ and the rest of law enforcement followed.
The fire department said it wanted half and half.” For those departments that do use encrypted communications, Jorgensen emphasized the importance of using standardized encryption instead of proprietary solutions that may cost less initially but can create long-term problems. “When we talked about standardized encryption, we talked about it for a specific purpose, and that was to ensure that, if Agency A and Agency B are encrypted, they can communicate,” Jorgensen said. “When you buy a proprietary encryption, you do two things. The first thing you do is you lock your system into that encryption mode. The second thing you do is you prevent other vendors from using that encryption. “What you’re really doing is saying that, ‘I’m not going to have interoperability in the encryption mode, unless I buy all my stuff from that vendor’—whoever that vendor is, because they all sell proprietary encryption.” Of course, using encryption requires all participating users to have the appropriate encryption keys in their radios.
Theoretically, this function can be done via over-the-air rekeying (OTAR), but workshop participants noted several logistical issues with that approach. Ward said he used a form of OTAR in the military, but radios that were taken out of network range or were turned off sometimes were missed, which created additional maintenance work. “I’m not a big fan of OTAR,” Ward said. “Over 18-odd years, I’ve developed the attitude of, ‘If I have to change the key, it’s going to be a physical change. We’re going to connect the machine to each individual device, because I still end up doing it anyway.’ “That’s my personal opinion on it. We don’t use it on our system at this time.” Holder said that handling encryption rekeying in house also allows the radio shop to assess the general condition of radios on a regular basis. “We always end up doing a certain amount of antenna changes, battery upgrades and fixing clips and things, when we do our programming,” Holder said.
What a horrible article, full What a horrible article, full of inane quotes, especially by Jorgensen. How is there no longer the “security element” to encryption if all fleet users have it?! The nitwits interviewed seem to be suggesting that with P25 encryption, all channels on the radio must be set-up for it. OF COURSE you don’t enable encryption on mutual-aid channels unless all potential mutual-aid responders have encryption with the same crypto key on their radios! Also, these days, most radios are capable of having several different crypto keys — the encryption key used by Narcotics or Internal Affairs on their channel doesn’t have to be the same crypto key used on Patrol channels — meaning both operations can utilize radios in a secure fashion, the special units having the crypto key for Patrol, but Patrol radios not having the ability to monitor Narcs or IA.
With the more frequent use of scanner radios and ‘scanner’ apps for iPhone & Android devices by criminals, law enforcement certainly does need to consider the benefit of encrypting day to day radio traffic such as suspicious vehicle calls, silent alarms, etc. I fully support encryption I fully support encryption for special investigation units that may be investigating criminal activities by technologically savvy entities. However, encrypting daily dispatch traffic alienates the public as they no longer know what their Police Department is doing. In addition, neighboring agencies that have our dispatch channels in their radios would lose that immediate interoperability function unless they also had encryption and we key-loaded their radios. Even with non-encrypted mutual aid channels, the smooth flow of information will be impeded.
Some of the boots on the street actually listen to neighboring agencies and start moving to assist before an official call for assistance is made. Using a common key for every channel is not wise either. If you desire to restrict access to specific channels, the best method is by limiting who has the encryption key for that channel. Encryption for specific units – Yes.
![P25 compliant radios P25 compliant radios](/uploads/1/2/5/4/125427098/850968410.jpg)
Encryption on a wholesale basis – No. Pretty awful article on Pretty awful article on encryption. The fellow who wrote the article does not seem to actually know much technically and operationally about encryption.
First, present day encryption available to public safety through the P25 standard requires the identical bandwidth of a non-encrypted call. Using encryption has zero spectrum impact. He is confusing the present day encryption of a true digital radio with older forms of analog based encryption which required increased bandwidth or a compromise in audio fidelity. Second, the writer creates the impression that encryption is an all or nothing proposition in a radio.
Nothing could be further form the truth, locally we utilize encryption on Talk Groups when needed and disable it when not needed. We routinely operate with other jurisdictions that never use encryption on their talk groups or our talk groups.
Encryption does not limit flexibility it simply adds another tool into ones tool box to take advantage of. Finally, I do agree with the author with respect to proprietary encryption standards.
I do not know of any proprietary encryption standard that has not been broken in the public domain. The only thing the use of proprietary encryption accomplishes is the defeat of interoperability. I for one would like to see the FCC pull the Type Acceptance for any digital radio sold for use in the Public Safety spectrum which does not exclusively utilize the P25 standards. Doing so limits one to using DES/DES-OFB/AES encryption and further enhances overall interoperability.
Like any technological tool we have at our disposal, the use of encryption requires planning, ongoing support and management. Vendors are not likely to be your best source of information when deciding to add encryption. Look to your APCO community, find others who have successfully implemented encryption into their operations and make plans based upon knowledge; then make the correct decision based upon your financial resources and operational needs. I don’t expect the article to I don’t expect the article to be a refereed journal article loaded with inline citations and a list of references at the end. I won’t hit Donny with a “terrible” for that.
He was tasked with distilling a complex topic down into simple terms and capturing the “word on the street,” which seems to be varied at best. The chief from New Hampshire expressed a common thread in the industry – poor information from what might be trusted sources. What can we attribute that to? A lack of dialogue, like we have generated here. How does 100% crypto dilute the effectiveness of security? As some here have already asserted, it is an erosion of public confidence. But aside from that, which is a contentious topic in and of itself, a full-on crypto mode presents opportunity and challenge for intercept.
Let’s look at reality: there’s little funding today just to maintain core functions, let alone effective administration of key management facilities which change keys frequently. The majority of operation is set-and-forget, until equipment is lost or stolen, then, as the interviewee from South Carolina indicated, it’s hands-on with a KVL rekeying a new crypto key. This is a snapshot of radio reality in terms that even an IT person can understand. If you wanted a journal article, take the time to do the research, then submit it to a peer reviewed journal. And, my own experiences with DES-OFB and AES are that use of clear P25 and coded P25 are imperceptible, except I don’t get the beep in coded, the light blinks faster, and the scanner sounds jumbled up. It’s nothing more than that (unlike the DVP days).
Agreed – voice scrambling in Agreed – voice scrambling in analog resulted in an unacceptable reduction in audio quality and system performance in our field trials. By contrast, our test group saw no change in audio quality with digital encryption. EXCEPT: When we used a form of encryption which relied on the radio’s general purpose CPU.
In those cases, the CPU load did affect the delivered audio quality. Once we changed algorithms and offloaded the encryption workload to an option board, everything was peachy. The issue isnt that every The issue isnt that every channel needs to be encrypted. The issue HERE is that the vendors, // and Harris is selling these systems and telling customers that they HAVE to do this. The onus needs to be placed there.
Anyone who bought a system because they were told they have to should lawyer up and sue the balls off of them. Of course encryption limits interoperability. Why do you think the NYPD hasnt done it yet? But Nassau County, just to the east of the city did.
Everything, including FD patch channels are going to be full encryption. It all comes down to who has the prettiest system, where I am from and it sickens me. Encryption is being sold as a Encryption is being sold as a panacea, With the illusion of privacy.
Encrypt everyone and you can say anything you want and no one will know. Vendors pushed encryption with deep discounts and the promise of keeping all those pesky scanner listeners away.
I support encryption for sensitive communications, but not for day to day traffic. Taxpayers paid for the system, and at a hefty price, in the case of Las Vegas Metro, nearly $60 million when it all said and done.
And it “none of your business” what we say on the radio? Bad policy.
If you’ve lost interest in that DVB dongle you bought to give software defined radio a try you should bust it back out. Harrison Sand just finished a guide on. The project, which results in the crystal clear audio reception heard after the break, uses a whole lists of packages on a Windows box to access the emergency bands. SDRSharp, which, handles the hardware work. In this case the dongle is a Newsky TV28T v2 module that he picked up for a few bucks. He’s also using some support programs including the Digital Speech Decoder which turns the data into audio. We wonder how many areas this will work for.
It was our understanding that law enforcement was moving to encrypted communications systems. But all we really know about it is that. Posted in Tagged, Post navigation. It’s not that they can’t agree on a standard. It’s that departments are funded separately. The state police might want to upgrade their system and tell everybody to use “Encrypted Gizmo 2013” but that means now the County Sheriff dept.
And the local Police have to buy all new equipment for their handhelds and vehicles. The local PD might barely have enough money to operate and can’t afford new radios. That’s not to mention the federal agencies involved either. I’m 99% they’d all be using the same standard if every time the protocol switched the federal government would buy the radios for everybody. Actually my example is Australia.
Also TETRA is really the defacto standard for modern 2-way communication, it’s just a question of who will pay for the infrastructure. In Great Britain the Airwave project was created in a public-private partnership which has the overseeing entity Airwave Solutions making money hand over fist every time anyone in the country hits the PTT button. In Australia the states have taken a dim view of going to the extent to encrypt communications and then route it through infrastructure owned by a private company, so instead they setup their own.
There’s no doubt the entire state will move to the same system eventually (in this case P25) however the move will take time. Also just because systems are not the same doesn’t mean you can’t bridge between them. We do this where I work, we bridge a local legacy Motorola Smartnet system to a Motorola TETRA system and to a MotoTRBO system 15km down the road owned and operated by another company with whom we have to remain in constant communication.
It’s a question of money, not standards. This post was worth reading just to find out about SDR# — I guess its time to break out the tuner again and try it. In the video, is the channel automatically going to the signal with the peak level, or is the user manually switching channels? I wish somebody would come up with a GNU or free version of Virtual Audio Cable, though. I’d kinda like to actually use the fancy audio subsystem on my new laptop in Windows (it is a corporate laptop, or otherwise it would have gone Linux the first week I had it). I’m using an RTL2832/E4000-based DVB-T dongle from Europe, and the IF noise(presumably) is just horrible. Spikes every 28kHz or so across the whole 2MHz slice and the thing gets hot after a while.
And the stock antenna does suck I don’t even think the “coax” is shielded. Its only about 1/16″ diameter. I had an old scanner mast dipole I broke out and ran RG-6 to it with a PAL(Bellman-Hughes or whatever) to F adapter. That vastly improved things as far the noise floor, but the spikes are still there(not to mention the huge LO spike in the middle). I personally use HDSDR but SDR# is good, too just not as much eye-candy. I’m planning on building a 125MHz NE/SA602-based upconverter for tuning HF and I’m thinking of putting the dongle in the box so I can isolate it from and RF and provide some forced-air cooling.
I’m gonna throw in a 1:1 balun/isolator on the inputs, just for S&G. Plus, if the dongle is in the box, I can provide it with a better ground than going though the guts of the computer through the USB. I’m having a bitch of a time sourcing a 125MHz oscillator that’s not SMD, though. I’ve never done SMD and I’m not sure if I’m really equipped for it. Soldering a bacon-bit isn’t exactly something I look forward to. I would much rather have a DIP-4 package. But Mouser stopped stocking them.
You sure those spikes are noise and not a function of the poor hardware dongle itself? I get the same thing when tuning in certain frequencies and I highly doubt the government would tolerate this kind of interference near airtraffic bands where I experience it. I am about to try a different dongle because of this. Also I suggest try the SMD route.
You may like it. It really is quite easy and the only special tool you need is a set of tweezers. Even a standard soldering iron is fine for SMD work, though the finer the tip the easier it is.
Kendall: Thanx! I completely forgot eBay! Garbz: I think they are indeed specifically from poorly filtered/shielded oscillator. It turns out the oscillator for this thing is 28.8kHz.
It’s worse in certain bands(like 2m 144-148MHz) I call the spikes noise because that’s what they are. Anything not a real signal is noise, including that caused by the hardware itself. In this case, I believe the term is “image noise”, in this case. In other words, yes, it’s the POS dongle I have:) As far as SMD goes, my hands aren’t the steadiest anymore Example: Steve: That is indeed my plan. And it’s an UPconverter; bringing the HF(DC-60Mhz) signals up to the range of the receiver(60-2200MHz), while keeping those signals out of the FM broadcast band(88-108MHz) so that the HF will be tunable by the receiver software(HDSDR) with a -125MHz offset (125-180MHz). I’m a little worried about the low HF I’m 1/4 mile from an AM broadcast station.
I occasionally hear it on my telephone and speakers(without being hooked up it’s spooky as hell walking into a room and hearing voices on a disconnected speaker!) The design I am basing the upconverter off of is that by W9RAN(featured in January 2013 QST and available for $40 in kit but I need to customize with compartmentalized shielding and stuff, and it includes manual bypass of the upconverter(separate HF, VHF/UHF antenna inputs). Another possible project is a downconverter for snagging signals over 2200MHz but I’ll need to lose the noise first, and I think an LNB would work for that but it’s not high on the priorities list. In building the HF upconverter, I’m going to need to have an internal 7805 to power the NE/SA602, and I was going to feed the dongle with that instead of the power from the USB. Basically, I am going to solely have the two data channels and the ground channel on the USB(I don’t like seeing isolated ground planes, plus it’s needed by the data channels). I would just connect to the computer at the box instead of at the dongle in one nice, clean package. After this, the next project would be an SDR transmitter stage, which I would incorporate with the receiver project stage to have a fully-functional transceiver. I just wish HRD supported SDRs other than Flex.
Maybe I’ll have to throw an ARM in there to simulate a known transceiver as far as the CAT software is concerned.