HELP NEEDED: Making a Counter Encryption Argument

[NJFFDisp]

I need a little help from the RR Community. I am part of a project team of a new trunking system build out (UHF P25 Phase II). I represent the Fire/EMS user group for this system. As an active member of this community I am against encryption as the next person on RR (for routine radio traffic). As such I am pushing for the Fire/EMS talkgroups to be in the clear. However, I am facing a massive amount of opposition and a push to encrypt all radio traffic on the new system.

Currently, my two points in opposition are:
1. Lack of Interoperability with Encryption. For this I have referenced the 9/11 Commission Report for the need to improve interoperability in radio communications.
2. Increased modulation with Encryption increases the ability to hear fireground radio transmissions. Note: We currently operate on a trunking talkgroup for fireground ops.

Does anyone else have any suggestions on any additional points to counter against the use of encryption. Also, does anyone know of any documentation, studies, or other reports countering the use of encryption. I remember the 2007 IAFC report on digital fireground radio use made several points against the use of digital radios on the fireground, but that report was seemingly replaced by the 2016 FEMA Voice Radio Communications Guide for the Fire Service, but no where in that guide does it make any recommendations against encryption.

Thank you for your help!

 

[buddrousa]

So who is pushing encryption on the system for FIRE/EMS?

 

[mmckenna]

I know this won't end well, but…..

Currently, my two points in opposition are:
1. Lack of Interoperability with Encryption. For this I have referenced the 9/11 Commission Report for the need to improve interoperability in radio communications.

Encryption doesn't impact interoperability as much as people think. Interoperability is a MUCH larger issue that needs to be addressed way ahead of/above encryption argument.
Trunking has a bigger impact on interoperability that encryption. If mutual aid agencies are not active users on the system, then it won't matter if it's encrypted or not. If they are users on the system, it's easy to manage encryption.
There are many established ways of handling the sharing of encryption keys. Usually the biggest issue is egos get in the way. You can fight this all day long, but if you cannot get past the chief level ego battle, there's no point in even trying.

Interoperability can be solved easily by using the IFOG channels. That is -exactly- what they are there for. It not only solves the encryption issue, but it solves the trunking access issues. If your radios don't have the IFOG channels in them, then you need to push for that.

I get what you are saying, but anyone experienced in running a system is going to shoot this one down. You'll need to come up with a better argument.

2. Increased modulation with Encryption increases the ability to hear fireground radio transmissions. Note: We currently operate on a trunking talkgroup for fireground ops.

This sentence doesn't make any sense to me.

Encryption has no impact on audio quality of a digital system. The 1's and 0's just get rearranged. The radio will decrypt them just fine on the other end.


Not trying to discourage you from trying to stop encryption, but you really need to work on some better arguments.

 

[nsrailfan6130]

I'm thinking someone from the high command or TRS managers.

So who is pushing encryption on the system for FIRE/EMS?

 

[prcguy]

For encryption, the organization in charge of the radios will need to spend more time and labor to deal with encryption or hire a custodian at additional cost. Whoever loads encryption keys should have some form of security clearance and be held responsible for them, otherwise security of the radio transmissions is only as good as the guy who has the key and he can give that out to friends or the press. If the radios are not set up right and encryption fails on a radio, others may not hear their broadcast, which could result in dead firemen. If encryption in the radios is field selectable you introduce more complications and training for the users.

There was a FD somewhere recently that went encrypted then there was a lot of complaining from scanner people or maybe some other group then the fire chief decided it wasn't a good idea and they removed encryption. If you can find who did that you might get some compelling info from a fire chief.

Bottom line you could throw at the proponents of encryption is, will they be responsible for any harm or death if encryption causes a problem with critical life or death communications.

 

[buddrousa]

Around here it is locked on or off by Channel/Talkgroup.
As noted above encryption is not a do it yourself project.
Also it will not be handled for free and someone will take the responsibility for it working without any problems.

 

[mmckenna]

For encryption, the organization in charge of the radios will need to spend more time and labor to deal with encryption or hire a custodian at additional cost. Whoever loads encryption keys should have some form of security clearance and be held responsible for them, otherwise security of the radio transmissions is only as good as the guy who has the key and he can give that out to friends or the press. If the radios are not set up right and encryption fails on a radio, others may not hear their broadcast, which could result in dead firemen. If encryption in the radios is field selectable you introduce more complications and training for the users.

Good points, but lots of systems are running encryption without these issues. Yes, it takes extra work, but running a large trunked radio system properly already takes a lot of work and knowledge.

As I'm sure you know, Dumb****s shouldn't be programming radios or radio systems.

Bottom line you could throw at the proponents of encryption is, will they be responsible for any harm or death if encryption causes a problem with critical life or death communications.

Applies to the entire system, encryption or not. Encryption is just an add on challenge.

Also it will not be handled for free and someone will take the responsibility for it working without any problems.

Like I said above, running a trunked system requires knowledgeable people that should already be on staff.

I've been running encryption on some talkgroups for 11 years now. There is no impact on audio quality or range. Key management isn't that difficult. But it does require some work. Hopefully anyone running a trunked system for a public safety agency would have the knowledge to do it correctly.

 

[mdulrich]

I'm retired from the fire service for 15 years so things may have changed, but check the NFPA standards. If memory serves me correctly they were against digital and trunking for fireground operations. When I was on the NFPA didn't even want fireground operations going through repeaters.

As a compromise, you could suggest encrypted talkgroups for things like fire investigation, EMS communications to hospitals, etc.

But I agree that fire and EMS really don't need encryption for their day to day operations. When I was on anything that we didn't want going out over the air was handled by cellphones by command officers.

Mike

 

[clbsquared]

Your interoperability argument isn’t going to get you very far. Patches can be put in place from the dispatch console to accommodate users of another agency on a different band. Also, talkgroups can be put in place for LE and Fire/EMS to communicate with each other that aren’t encrypted. You can have mutual aid talkgroups added to accommodate systems of the same from bordering or neighboring jurisdictions. You can argue interoperability all you want to. Those obstacles can be overcome. Interoperability is a mindset. You either choose to use it or you don’t. Many many systems are sold on the sales pitch of interoperability. When it comes down to it. Most of those systems will never use it anyway. Case and point, my county recently spent $15 million on a P25 system. Between LE and Fire/EMS we have 46 talkgroups just for our county alone. Not mutual aid. 46 talkgroups for a county of 350 square miles. Of those 46 talkgroups, 8 have been used since it went online. We have zone after zone after zone of mutual aid channels for the same type of 700/800 systems for every jurisdiction and agencies in our area. Some as far away as 35 miles. But by golly we got them. Ever been used? Nope!! Over 2 years and never used them. Our region spent millions upon millions on ORION specifically for interoperability. Do we use it? Nope, dispatch just patches one channel to another and sends it to one of our TAC channels. When you’re in the thick of things, the last thing you want to be worried about is “what zone is that agency in”? “What talkgroup are they using”?
I could go on and on, but I think you get my point. Interoperability is a mindset. You have to be prepared for it, train for it, implement it when necessary. Otherwise it’s just gonna be “dispatch, can you patch them through to our channel”?

 

[xmo]

Mike wrote: " I'm retired from the fire service for 15 years so things may have changed, but check the NFPA standards. If memory serves me correctly they were against digital and trunking for fireground operations. When I was on the NFPA didn't even want fireground operations going through repeaters "
-----------
I also remember that. After several comm debacles starting with the WTC, a lot of attention was focused on interoperable and reliable communications for first responders. There were many advocating simplex on the fireground.

However, NFPA changed directions 180 degrees. Agencies want to keep responders on their system. The fire guys remembered that they have a big hammer and they have decided to use it.

The hammer? Fire code, fire marshals, and permits. So, fire codes now say that building owners are responsible to ensure that responders have the same capabilities inside a building as they do outside of said building. Overnight, ERRCS has become a billion dollar industry.

As to the original topic, interoperability can't be used as an excuse to not implement encryption. All it takes to have interoperable communications is pre-planning, correct radio programming, and training users to turn a knob .

Our region has many agencies interoperating on a daily basis through talkgroup sharing between agencies and regional talkgroups in every radio. Even encrypted talkgroups are shared through authorization agreements an key sharing.

It's sad to hear of situations like clbsquared reported. It's a thing of beauty to see a system where all the grant and taxpayer dollars have been invested in meeting everyone's needs. It all starts with agencies talking to each other in meetings, deciding what they need and want, and tasking the comm guys to 'make it so'.

 

[Ensnared]

I don't know anything to cite, but I know there are a group of individuals in California who have organized a petition to challenge this activity. You might want to check their arguments.

Here is what I've never ever heard: "Can anyone cite one incident where an officer was killed or hurt in the line of duty from someone listening to a police scanner?"

In San Angelo, Texas, a police chief was charged with various felonies associated with accepting dirty money from those who were associated with their trunked radio system.

However, the main drive in many areas of this country originate from Homeland Insecurity. That is my take and opinion, thanks.

 

[IMPRES2]

When you’re in the thick of things, the last thing you want to be worried about is “what zone is that agency in”? “What talkgroup are they using”?

This is where I advocate for spending a bit more money for Geo Services and Dynamic Regrouping. The user doesn’t have to worry about what zone or “channel” the traffic is on because the incoming radios hit a temporary Geo-Fence and Dynamically Regroup to the right “channel” automatically.

 

[2154]

I'll echo what mmckenna said too. I know a couple of systems that have been running full encryption for years now on every single talk group including tac's with no issues at all. One in particular hasn't changed the keys and thus has just kept them all the same since the initial programming. But if you do change out the encryption keys, that would need to be coordinated properly and could be a nightmare if not handled well. Otherwise, having the full encryption allows you to filter out what is needed to go to the media, what can be released for the public, and what needs to be kept in house (frankly sometimes stuff gets said on the radio by our folks that makes one wanna facepalm and would rather not be heard elsewhere). It saves you from broadcasting where a missing body has just been located during a disaster & having folks flocking to the area to catch a glimpse. To aid with your media folks, one county has two base station setups with the encrypted TaGs they can give to a media rep and are set with no tx allowed but would allow them to monitor the event if desired (this would be coordination on what size/type event you wanted to "issue" these out.)

Fireground tactical communications should be kept on a conventional side and not going through a system. This point has been hammered repeatedly by NFPA & NPSTC for years and there's a number of after action reports that unfortunately echo the reasonings for this. Use your NIFOG channels for this. They're way underused as it is. As to encryption on these or not, keeping these in the clear could provide a benefit but so could having them strapped. Digital vs analog-your choice. Theres benefits to both and I'd venture to sway digital but do some realistic training with your radios & see what works best. Play with the audio settings on both to see if there's some gain settings that can be tweaked to pick up the audio through a voice amp & speaker mic while in a noisy environment. These are the things that are most of the time overlooked & take a little effort, but can make that life or death difference when a mayday is called on a structure fire.

Audio clarity wise, encryption won't hurt that and the bigger key would be having your audio settings set right in the profiles.

 

[NJFFDisp]

So who is pushing encryption on the system for FIRE/EMS?

The push for encryption began with the contracted system engineering team. IT, Cyber Security which is part of the team project due also pushed for it. With those stakeholders pushing the concept the project manager (who has little experience in wireless communications)+

So who is pushing encryption on the system for FIRE/EMS?

Contracted System Engineers and IT: Cyber Security started pushing the concept and the project manager (not from Wireless Communication Field) ran with it.

 

[xmo]

" Fireground tactical communications should be kept on a conventional side and not going through a system. This point has been hammered repeatedly by NFPA & NPSTC for years "
-------------
Please cite appropriate IFC510 and NFPA1225 sections.

With respect to the original topic - in today's world there are zero supportable arguments against encryption. ZERO

Audio quality and range concerns are based on ancient history and have no relevance today. Interoperability of any kind requires planning, programming and training - regardless of whether encryption is used or not.

"Transparency" - that's easy. Real time access for media and delayed feeds for the general public. Nothing is hidden.

Complaints from a few scanner hobbyists? Just background noise.

 

[mmckenna]

" Fireground tactical communications should be kept on a conventional side and not going through a system. This point has been hammered repeatedly by NFPA & NPSTC for years "
-------------
Please cite appropriate IFC510 and NFPA1225 sections.

In the older versions (1221):

9.3.1.3* A communications radio channel, separate from the radio dispatch channel, shall be provided for on-scene tactical communications.
9.3.1.4* At a minimum, the tactical communications channel identified in 9.3.1.3 shall be capable of operating in analog sim- plex mode.
9.3.1.5 Trunked system talk groups shall not be used to fulfill the requirements of 9.3.1.3 and 9.3.1.4.

I'm sure NFPA has changed it to benefit large radio Manufacturers.

 

[xmo]

" I'm sure NFPA has changed it to benefit large radio Manufacturers "
------------
Agencies don't want to go back to stone knives and bearskins. They want to stay on their system and not be on a simplex island. With simplex, a dozen confused firefighters all trying to talk at the same time means nobody gets heard. On the system, the first user gets through and the rest get reject bonks so they know they weren't heard.

While radios are on the system - every transmission is tracked and timestamped (ATIA logs). Logging recorders can capture all incident related traffic. IC and other firefighters can see the ID of every transmission. Keeping alias lists up to date is easy with radio management.

With location, the system knows where every user is. CAD controls reporting cadence so "at incident" user locations are updated more frequently. Location on emergency and location on PTT give immediate updates.

The advantages of staying on the system have driven the code changes (maybe with a little nudge from vendors)

 

[mmckenna]

The advantages of staying on the system have driven the code changes (maybe with a little nudge from vendors)

And that's not a bad thing.
But if you look at the names/companies that write the NFPA stuff, you start to see a trend.

There's plenty of agencies that use simplex fireground channels without issue.

 

[PrivatelyJeff]

And that's not a bad thing.
But if you look at the names/companies that write the NFPA stuff, you start to see a trend.

There's plenty of agencies that use simplex fireground channels without issue.

Yep. Everyone here in the Central Valley does and so does CALFire, for a simple reason: it works. You can be in a crap location and can’t hit the repeater but you can sure as heck hit the radio outside the fire.

 

[12dbsinad]

" Fireground tactical communications should be kept on a conventional side and not going through a system. This point has been hammered repeatedly by NFPA & NPSTC for years "
-------------
Please cite appropriate IFC510 and NFPA1225 sections.

With respect to the original topic - in today's world there are zero supportable arguments against encryption. ZERO

Audio quality and range concerns are based on ancient history and have no relevance today. Interoperability of any kind requires planning, programming and training - regardless of whether encryption is used or not.

"Transparency" - that's easy. Real time access for media and delayed feeds for the general public. Nothing is hidden.

Complaints from a few scanner hobbyists? Just background noise.

Try telling that to the family members of the LODD's that are directly related or pertain in part to failed TRS's used on the fireground. Have you ever been bonked in a burning building? It isn't a real good feeling when all I want to do it talk outside a wall..