Here's the full story:
http://urgentcomm.com/p25/panel-p25-enc ... t-everyone
Encryption is NOT for Everyone
Re: Encryption is NOT for Everyone
Be sure and read all of the comments following the article. As one of the commentators mentioned, the author had to distill a fairly complex subject down to generally simple terms; some compromises tend to creep in in such cases.
The bandwidth issue is odd, I feel, as does another of the comment postings. Applying the common encryption schemes to P25 audio should not affect the bandwidth of the signal; as the poster in the comments stated, this seems like an old holdover from the old analog FM encryption methods and their inherent problems.
Voice quality, too, isn't the problem it once was. I have read various reports on this but I don't see a technical reason that there should be any serious degradation in P25 audio given the digital nature to begin with (you are effectively just mapping the bits differently in a unique coded fashion - the A/D is always done anyway so nothing new is added for that). If there is a noticeable difference, it may be due to extra latency caused by the extra level of computation involved...??
Anyway, it's a complex issue that has many operational as well as technical levels; each system case is unique.
-Mike
The bandwidth issue is odd, I feel, as does another of the comment postings. Applying the common encryption schemes to P25 audio should not affect the bandwidth of the signal; as the poster in the comments stated, this seems like an old holdover from the old analog FM encryption methods and their inherent problems.
Voice quality, too, isn't the problem it once was. I have read various reports on this but I don't see a technical reason that there should be any serious degradation in P25 audio given the digital nature to begin with (you are effectively just mapping the bits differently in a unique coded fashion - the A/D is always done anyway so nothing new is added for that). If there is a noticeable difference, it may be due to extra latency caused by the extra level of computation involved...??
Anyway, it's a complex issue that has many operational as well as technical levels; each system case is unique.
-Mike
Re: Encryption is NOT for Everyone
I just wish Pasadena PD read this article.
Re: Encryption is NOT for Everyone
It's a mediocre article that rehashes known issues that get dealt with through proper planning. It's not going to change any minds as to whether or not to encrypt.
Re: Encryption is NOT for Everyone
I agree with the previous commentator. The article was relatively naive when the subject is viewed comprehensively, and accordingly it has received quite a bit of criticism from the industry professionals in the comments section.
One of the key flaws of the article is found in the first sentence where the hypothesis that "P25 systems managers should establish policies to help ensure that encryption is used only when necessary" is put forth. The problem with this hypothesis is that "when necessary" is very subjective and becomes difficult to define. The article goes on to say "encryption was intended for high-security risks, not just day to day traffic". Is responding to a bank robbery in progress a "high security risk"? I would argue that it is for sure.
Is encryption "necessary" when the burglars are using a scanner to monitor the patrol dispatch channel while they go out and trigger alarms then sit back and wait for the call to come over the scanner, and if one does, move on the the next location and if one does not then burglarize the place? ~Probably so.
Is encryption "necessary" if bank robbers are monitoring the patrol dispatch channel to hear if someone has hit the silent alarm? ~Probably so.
Is encryption "necessary" if sexual predators, child molesters, burglars or robbers use scanners to monitor dispatch channels while they are "casing" their victims to see if anyone has called in on them acting suspicious? ~Probably so.
Is encryption "necessary" for an officer doing a traffic stop or responding to the scene of a collision or a vicious animal or responding to a call for a fight in the street? ~Probably not.
Primary dispatch channels carry traffic that probably should be encrypted (i.e. dispatch to a bank robbery in progress or dispatch of burglar alarm activations) and some traffic that probably does not need to be encrypted. System managers have to balance out the concerns of transparency advocates and the media against the safety of their subscribers. If the system manager can encrypt and does, he/she will receive all sorts of "flak" from the press, hobbyists and transparency advocates. If the system manager can encrypt and chooses not to and an incident happens where a suspect was able to ambush and kill an officer while committing a burglary or robbery because he/she was given the advantage of knowing the officers were coming, the system manager has to live with that.
The idea that "SWAT, Narcotics, etc." are the only applications that "need" encryption is seriously flawed when you consider some of the most dangerous calls for service are "in-progress" calls, which are always handled on the primary dispatch channels. Most SWAT calls and special operations are situations that are carefully (pre)planned out and there is a huge amount of resources and backup already at the scene acting more "proactively" than "re-actively". Also consider this, If you get stopped by law enforcement for a traffic violation, etc. often times your drivers license number, date of birth, and name are broadcast IN THE CLEAR on primary channels so the dispatcher can confirm your driver's license status and if you are wanted. Your personal info is being put out for the entire world to copy down and use however they'd like to impersonate you.
The article continues on to argue against encryption from the standpoint of interoperability. This makes no sense to me from an operational standpoint. There are dedicated clear channels set aside specifically for interoperability on all the public safety bands and most governing agencies that oversee these channels (Cal-EMA) here in Ca., and Federal agencies have policies in place that ban or discourage encryption on the interoperability channels. Interoperability on PRIMARY channels does not happen on a day to day basis anyway, largely due to the fact that different agencies use different frequency bands, different emission types and in many cases different proprietary systems.
Someone had previously mentioned Pasadena PD here. I still haven't figured out why everyone has been giving Pasadena such a hard time over encrypting their PD traffic when all of Orange County has been doing this for over 10 years and we have hardly heard a peep about it. That being said, as a result of the pressure a local paper in particular in Pasadena has put on Pasadena PD, the dispatcher now had TWO foot pedals. A press of BOTH foot pedals sends console audio to both the encrypted Pasadena PD talk group and an unencrypted Pasadena talk group so the media, nosey people, and scanner enthusiasts can still hear the dispatch calls. The operator then can selectively choose which traffic is heard on the clear and which traffic is sent securely. A rather novel approach to the situation. Another solution might be a delayed audio feed of the radio traffic made available to the public with a 30 min (or so) delay and run want and driver license checks on a separate secured channel.
One of the key flaws of the article is found in the first sentence where the hypothesis that "P25 systems managers should establish policies to help ensure that encryption is used only when necessary" is put forth. The problem with this hypothesis is that "when necessary" is very subjective and becomes difficult to define. The article goes on to say "encryption was intended for high-security risks, not just day to day traffic". Is responding to a bank robbery in progress a "high security risk"? I would argue that it is for sure.
Is encryption "necessary" when the burglars are using a scanner to monitor the patrol dispatch channel while they go out and trigger alarms then sit back and wait for the call to come over the scanner, and if one does, move on the the next location and if one does not then burglarize the place? ~Probably so.
Is encryption "necessary" if bank robbers are monitoring the patrol dispatch channel to hear if someone has hit the silent alarm? ~Probably so.
Is encryption "necessary" if sexual predators, child molesters, burglars or robbers use scanners to monitor dispatch channels while they are "casing" their victims to see if anyone has called in on them acting suspicious? ~Probably so.
Is encryption "necessary" for an officer doing a traffic stop or responding to the scene of a collision or a vicious animal or responding to a call for a fight in the street? ~Probably not.
Primary dispatch channels carry traffic that probably should be encrypted (i.e. dispatch to a bank robbery in progress or dispatch of burglar alarm activations) and some traffic that probably does not need to be encrypted. System managers have to balance out the concerns of transparency advocates and the media against the safety of their subscribers. If the system manager can encrypt and does, he/she will receive all sorts of "flak" from the press, hobbyists and transparency advocates. If the system manager can encrypt and chooses not to and an incident happens where a suspect was able to ambush and kill an officer while committing a burglary or robbery because he/she was given the advantage of knowing the officers were coming, the system manager has to live with that.
The idea that "SWAT, Narcotics, etc." are the only applications that "need" encryption is seriously flawed when you consider some of the most dangerous calls for service are "in-progress" calls, which are always handled on the primary dispatch channels. Most SWAT calls and special operations are situations that are carefully (pre)planned out and there is a huge amount of resources and backup already at the scene acting more "proactively" than "re-actively". Also consider this, If you get stopped by law enforcement for a traffic violation, etc. often times your drivers license number, date of birth, and name are broadcast IN THE CLEAR on primary channels so the dispatcher can confirm your driver's license status and if you are wanted. Your personal info is being put out for the entire world to copy down and use however they'd like to impersonate you.
The article continues on to argue against encryption from the standpoint of interoperability. This makes no sense to me from an operational standpoint. There are dedicated clear channels set aside specifically for interoperability on all the public safety bands and most governing agencies that oversee these channels (Cal-EMA) here in Ca., and Federal agencies have policies in place that ban or discourage encryption on the interoperability channels. Interoperability on PRIMARY channels does not happen on a day to day basis anyway, largely due to the fact that different agencies use different frequency bands, different emission types and in many cases different proprietary systems.
Someone had previously mentioned Pasadena PD here. I still haven't figured out why everyone has been giving Pasadena such a hard time over encrypting their PD traffic when all of Orange County has been doing this for over 10 years and we have hardly heard a peep about it. That being said, as a result of the pressure a local paper in particular in Pasadena has put on Pasadena PD, the dispatcher now had TWO foot pedals. A press of BOTH foot pedals sends console audio to both the encrypted Pasadena PD talk group and an unencrypted Pasadena talk group so the media, nosey people, and scanner enthusiasts can still hear the dispatch calls. The operator then can selectively choose which traffic is heard on the clear and which traffic is sent securely. A rather novel approach to the situation. Another solution might be a delayed audio feed of the radio traffic made available to the public with a 30 min (or so) delay and run want and driver license checks on a separate secured channel.
Last edited by N6AJB on Mon Jul 29, 2013 2:04 pm, edited 12 times in total.
Re: Encryption is NOT for Everyone
Also, there are always the good old MDTs.
Re: Encryption is NOT for Everyone
N6AJB, excellent post, written from a law enforcement prespective, but probably not what anyone on here wants to hear. Thank you.
Re: Encryption is NOT for Everyone
I agree, this is a valid solution to the identity theft aspect of the situation. Unfortunately MDT's aren't feasible when dealing with "in progress" calls issue due to the fact there may be personnel very close to the scene out of vehicles either or in unmarked capacities that need to know what is happening and may literally be right next door to where a burglar alarm was just set off.cvrules90 wrote:Also, there are always the good old MDTs.
MDt's would not be a good choice to coordinate a response to a bank robbery either.
Also, sometimes officers can't sit in the car while running someone due to a safety or flight risk unless another officer is able to "babysit" the person(s) detained while the other officer uses the MDT. That being said, cellular telephones could also be used that might be a good compromise for that particular instance.
Last edited by N6AJB on Mon Jul 29, 2013 10:49 am, edited 1 time in total.
Re: Encryption is NOT for Everyone
Well, also coming from the hobbyist perspective. I have been into scanning since the 1980's and up until recently monitored law enforcement exclusively. From the perspective of my own self interests, I am against encryption simply because it ruins my fun. However, from a practical standpoint I hate to say it but I do see really strong arguments for using it.sp1989 wrote:N6AJB, excellent post, written from a law enforcement perspective, but probably not what anyone on here wants to hear. Thank you.
I guess it's a shame that historically bad guys have used monitoring to their advantage. One of the things that has given system administrators the "eeby jeebies" (for lack of a better term) is seeing their system traffic being distributed to everyone's cellphones. Before, to monitor it took just a bit of technical skill and a research and a receiver. Now, anybody with a smartphone is just a couple clicks away to being able to tell if the police are coming and they don't even have to be in the area to do it...an accomplice in Egypt could theoretically be doing it for them and simply give them a call when they hear someone is coming. Heck, someone in Nigeria can be listening to the scanner feeds as well and be writing down people's personal info to be used for nefarious purposes.
As fun as the "feeds" are they do add a new dynamic to things.
Re: Encryption is NOT for Everyone
Many good points right here. Another way to tackle this solution is to encrypt partially. That is, keep all your talkgroups clear 98% of the time, and encrypt during a highly sensitive operation. That way, burglars and other crooks won't use the messages to their advantage to accelerate in that getaway car.
It's a shame how departments also keep dispatch channels open, but encrypt all secondary channels (they love doing it that way in Phoenix for example). IMHO, ALL channels should be in the clear by deafult, but the administrator should make encryption available so that it can be turned on or off at the dispatcher's or officer's discretion.
And by the way, law enforcement encrypts more content than fire.
It's a shame how departments also keep dispatch channels open, but encrypt all secondary channels (they love doing it that way in Phoenix for example). IMHO, ALL channels should be in the clear by deafult, but the administrator should make encryption available so that it can be turned on or off at the dispatcher's or officer's discretion.
And by the way, law enforcement encrypts more content than fire.