Encryption on a P25 or DMR system is applied one transmission at a time by the radio that is talking, which means a talkgroup is only as secure as its worst-programmed portable. When a single radio goes out in the clear, the audio sounds exactly the same to everyone else on the group, and depending on how the receiving radios are configured either nobody notices or the clear unit quietly stops hearing the talkgroup at all. This piece covers nine ways that happens, what each one looks and sounds like on the air, and the call record audit that will find most of them in an afternoon.

Encryption is applied per transmission by the radio that is talking

A talkgroup is an address. On a trunked P25 system it tells the infrastructure which subscribers should be granted a channel and which radios should unmute, and it carries no cryptographic property of its own, because the system core is switching a call rather than protecting one. The protection, when it exists, is applied inside the transmitting radio before the audio ever reaches the air, and every receiving radio then has to decide what to do with what shows up. That single architectural fact is the reason a talkgroup labeled SECURE in your fleetmap can carry traffic that anybody with a scanner can hear.

The P25 air interface carries the state of each transmission in the transmission itself. The security analysis of P25 published at the USENIX Security Symposium in 2011 by Sandy Clark, Matt Blaze and their co-authors describes the header as containing a Message Indicator, which is the initialization vector and is 72 bits wide but effectively 64, along with an eight bit Algorithm ID and a sixteen bit Key ID, and it notes that transmissions sent in the clear set those fields to all zeros. A radio talking in the clear on an encrypted talkgroup is not doing anything the protocol considers an error, so nothing rejects it, nothing logs an exception, and the infrastructure passes it along the way it passes everything else.

The practical consequence is that the security of a talkgroup is set by the worst-configured radio that is affiliated to it, and the failure is per transmission rather than permanent. The same portable can be secure on Tuesday and clear on Wednesday because a switch moved in a turnout pocket, and it can be secure for a supervisor’s key-up and clear for the next one from the same unit if the operator bumped something between them. An audit built around asking whether a radio is encrypted will not find this, because the answerable version of the question is what fraction of that radio’s transmissions on that talkgroup over the last thirty days went out protected.

What the rest of the group hears depends on their own programming. If the receiving radios are configured to accept unencrypted audio on that talkgroup, the clear transmission plays through the speaker sounding identical to every other transmission, and the leak is invisible to the people best positioned to catch it. If the receiving radios are configured to reject unencrypted audio, they mute it, which means the clear unit is transmitting into a hole and nobody on the group hears him at all. Both outcomes come out of the same underlying condition, and most agencies I have dealt with have never decided in writing which one they want.

Selectable, strapped, and what a receiving radio does with clear audio

The published programming guidance from statewide systems is consistent on the vocabulary here. The Michigan Public Safety Communications System encryption best practices document and the Indiana Integrated Public Safety Commission encryption programming guidelines both describe three encryption activation states for a talkgroup in a codeplug: clear, meaning encryption is off and cannot be turned on; selectable, meaning the user can turn encryption on and off with a switch, a button or a menu; and strapped or secure strapped, meaning the talkgroup is always encrypted and the user cannot turn it off. Indiana’s guidance recommends secure strapped for talkgroups that will always be encrypted, giving tactical, narcotics and SWAT groups as its examples, and it recommends that a talkgroup which genuinely needs both modes be programmed twice, once clear strapped and once secure strapped, rather than left selectable.

Selectable is where the accidental clear transmission lives. In the slides Matt Blaze presented to the federal Information Security and Privacy Advisory Board in October 2012, he described radios as typically configured with a two position switch controlling outbound crypto, described that switch as often obscurely marked and out of view, and said user-selected was the standard configuration at that time. Whether that is still the standard configuration on your fleet is a question for your own codeplug rather than for a fourteen year old slide deck, and it is worth checking talkgroup by talkgroup instead of assuming. On the air, this failure is silent, because the transmission carries normal audio and normal unit ID and the only local indication is on the radio of the person who caused it.

The receive side is the decision most agencies never made deliberately. A radio can be configured to unmute clear traffic on a secure talkgroup, in which case the group keeps working and the exposure is hidden, or it can be configured to discard clear traffic on that talkgroup, in which case the exposure stops and the offending unit is effectively off the air for his crew. The second one is a real officer safety condition, because a deputy transmitting a location or an assist request into a group that has muted him has no way of knowing his traffic is going nowhere except that nobody answers, and the natural human response to nobody answering is to repeat the transmission rather than to change radios.

The names for these settings, where they are found in the programming software, and what they default to all vary by manufacturer, by model and by firmware version, and I am not going to assert a default for any vendor here because I cannot verify it across a fleet I cannot see. What I will say is that you can determine it in twenty minutes with two radios, a spare talkgroup and a supervised test on your own system, and that the answer belongs in your radio programming documentation in one sentence so that the next technician does not have to rediscover it.

Missed rekeys, dead keys, and the radio in the drawer

Encryption keys on a P25 system are handled with more moving parts than most people outside the radio shop realize. The Iowa statewide system’s published over-the-air rekeying standard describes the arrangement plainly: a traffic encryption key is what encodes the transmission, it is stored against a key identification number and a decimal storage location number, and a subscriber updating its keys over the air authenticates to the key management facility using a unique key encryption key that was assigned to it either by the facility or by a trusted technician using a key fill device. Every one of those elements is a thing that can be wrong on one radio while being right on the other four hundred.

Over-the-air rekeying only reaches radios that are powered on, affiliated and in coverage during the rekey, which is why key management facility products advertise store and forward capability, as Motorola Solutions does in its published fact sheet for the ASTRO 25 key management facility. The radios that miss are predictable: the spare in the battalion chief’s trunk, the loaner that went out to a reserve, the cache radios in the trailer, and the portable of the member who was on vacation for two weeks. Michigan’s encryption best practices document also flags a codeplug setting it calls infinite key retention, and states that if it is not selected the radio loses all keys when power is removed, which turns a dead battery into a key event rather than a battery event.

What a radio actually does when it has no valid key for a strapped secure talkgroup is the single most important behavior in this article that I am not going to state for you, because it varies by manufacturer, by model and by configuration, and getting it wrong in either direction is worse than admitting the uncertainty. The possibilities include refusing to key up, keying up with an error tone, muting the talkgroup entirely, or in some configurations falling back to clear. Test it yourself with a spare radio and a supervised on-air test, get the answer in writing from your system administrator or your vendor’s technical support, and write the answer into your programming documentation with the date and the firmware version it was tested on, because it can change with a firmware release.

Spare, cache and loaner radios deserve a named owner for this reason alone. A radio that was never keyed, a radio that was keyed from a key fill device holding last year’s material, and a radio that was programmed from an older codeplug with the talkgroup left clear will all behave differently and all fail in ways the user cannot diagnose at three in the morning. The fix is administrative rather than technical, which is that the same person who runs the rekey runs it against an inventory list that includes every radio not in daily service, and signs the list.

Programming pushes and console positions

A fleet-wide codeplug push is the most efficient way to break encryption on a talkgroup, because it applies the same error to every radio at once and it arrives with the authority of the radio shop behind it. The mechanisms are ordinary: a template change that reverts a talkgroup’s encryption attribute to clear, a key assignment that does not carry across when a talkgroup is copied between zones, a storage location number that got renumbered on the system side but not in the subscriber template, or a technician who built the new codeplug from an archived file rather than from the current one. None of these announce themselves, and the radio comes back from programming looking normal on the display.

The only reliable detection is a supervised on-air test after the push, before the radios go back into service. Take two radios from the batch, put them on the affected talkgroup, key up, and confirm on a third radio and at a console position that the transmission is showing as encrypted, then confirm the reverse direction. That test takes about five minutes per talkgroup and it belongs in the programming procedure as a required step with a signature line rather than as something conscientious technicians happen to do. If your fleet is large enough that pushes go out in batches, the test happens on the first batch and again on the last one, because the batches are not always built from the same file.

Console positions are a category of their own because dispatch talks more than any field unit and its traffic is the most sensitive on the system, since it aggregates everything. A console position with the wrong key loaded, with the wrong talkgroup mapping, or with a transmit setting that sends clear will leak continuously and will leak the summary version of events rather than a fragment. Motorola’s published data sheet for the MCC 7500 console describes encryption and decryption occurring within each dispatch operator position and describes the console providing indicators and alerts when the console mode does not match that of a received call, and when a patch or multi-select group is being set up between a mix of clear and secure resources. I am citing that as an example of what a console can be built to do rather than as a description of your console, and the right move is to ask your console vendor and your system administrator in writing what alerting your positions actually have, whether it is enabled, and where it displays.

Console alerting has a second failure mode that has nothing to do with software, which is that an alert appearing in a corner of a screen at a busy position at shift change is an alert nobody acts on. If your console does raise a mismatch indication, the shift supervisor needs to know what it looks like, what it means, and what to do about it, and that briefing takes one training bulletin and five minutes at a shift meeting you already hold.

Patches: the leak that dispatch creates on purpose

Patching an encrypted talkgroup to a clear one moves the audio, and audio that leaves a patch on a clear resource is in the clear regardless of how it arrived, because the patch bridges the conversation rather than the protection. Mutual aid is where this happens, since the mutual aid partner is on a different system or lacks the key, and the dispatcher solving the immediate problem of two agencies who cannot hear each other is doing exactly what the console was bought for. The exposure is not the dispatcher’s error so much as the absence of a rule telling her which resources may be bridged and who authorizes it.

The Iowa Statewide Interoperable Communications System Board’s published patching guidance makes the visibility problem explicit. It describes a soft patch as one initiated at the dispatch console and handled within the trunked system core and the site control channel, requiring no additional hardware, and states that it requires no change in operation for units in the field and is done without any notice to the users. A hard patch, in the same document, is one built with physical gateway equipment and subscriber radios, used to bridge different radio systems, and available for a communications unit technician to build at an incident. In both cases the field user hears his own talkgroup working normally and has no indication that his traffic is also going somewhere else.

Patch policy is short and it is enforceable. Name the roles authorized to create a patch involving an encrypted resource, which is usually a dispatch supervisor or a communications unit leader at an incident rather than any position on the floor. Require that the creation of a mixed clear and secure patch be announced on the encrypted talkgroup so the users on it know their traffic is leaving the group, which is the only step in this article that field personnel can act on themselves. Require that patches be logged with the time, the resources, the requester and the authorizer, and that every patch has a stated teardown condition, because the patch that nobody remembers to break is the one still running when the tactical channel goes back to routine use.

Indiana’s programming guidance takes the problem from the other direction and recommends against encrypting talkgroups that are used for interoperability at all, which is worth thinking about before you reach for a patch as the standing answer. If a regional tactical talkgroup exists so that four agencies can work together, encrypting it and then patching around the agencies that lack the key produces less security than leaving it clear and disciplining what gets said on it, and it produces that result while everyone involved believes the opposite.

Encryption that is not encryption, and fleets that do not match

Some agencies auditing this will find that the answer to whether their encryption is on is that they never had any. DMR basic privacy is a scrambler rather than a cipher, and the technical descriptions of it are unflattering: Wavecom’s decoder documentation describes basic mode as using a scrambler, calls it simple and weak, and notes that the same plaintext always produces the same ciphertext, which is the property that makes it analyzable. The Crypto Museum’s summary of DMR states that by default DMR is not secure and that eavesdropping is more complex than with analog FM rather than prevented, since receivers capable of decoding a DMR stream are commercially available. Analog voice inversion sits in the same category and has for decades, since inverting the audio spectrum makes speech unintelligible to a casual listener and reversible to anybody who wants to reverse it.

The standards-level answer on P25 is unambiguous. The Department of Homeland Security’s Office for Interoperability and Compatibility, in its published statement of P25 compliance assessment encryption requirements, states that the P25 standard encryption algorithm is AES 256 and that the TIA-102.AAAD-B Block Encryption Protocol document, originally published in July 2002, defines AES 256 for P25. L3Harris makes the same point in its published P25 encryption white paper, describing AES-256 as the standard encryption for P25 voice communications and the only approved algorithm for federal sensitive but unclassified communications, and it names the two concerns with non-AES encryption as a false sense of security and a loss of interoperability between agencies. Tennessee’s published statewide system user guide requires AES-256 for interoperable encryption on that system and states that use of ADP is at the partner agency’s discretion but does not meet best practices or federal standards.

Mixed-vendor and mixed-generation fleets fail at the algorithm layer before they ever get to keys. The DHS document states the requirement in one line, which is that every radio in a group must use the same encryption algorithm and key, and that while matching keys can be loaded into subscriber units in a straightforward way, the same algorithm must be present in each unit before keys can be loaded at all. An agency that bought AES capable portables for the tactical team and left DES or a vendor proprietary algorithm in the older mobiles has a talkgroup that cannot be made uniformly secure by any amount of key management, and the symptom in the field is a subset of units that cannot hear a subset of other units for reasons that look like coverage.

DMR does not have a single mandated public safety algorithm in the way P25 does, and what your DMR radios support ranges from basic privacy through vendor proprietary schemes to AES depending on the manufacturer, the model and what was licensed on it. Before you assert that your DMR fleet is encrypted to a public safety standard, get the specific algorithm and key length in writing from your vendor for each model you own, and check it against the current DMR Association and vendor documentation rather than against a spec sheet from the year you bought them.

The call record audit

Everything above is detectable, and the most useful detection method costs nothing but an afternoon of somebody’s time. Encryption state travels with each transmission, which means a trunked system that records call events has, in principle, a record of whether every individual transmission on every talkgroup was protected or clear, along with the radio ID that sent it and the time it happened. Pull a month of call detail records for your secure talkgroups and count the transmissions that went out clear. If the number is zero, you have documented that your encryption is on, which is a thing you can hand to a chief who asked. If it is not zero, the same records tell you which radios did it, when, and how often, and that list is your work order.

Whether your particular system exposes that field in its reporting tools, what it is called, and how long the records are retained are questions for your system administrator or system manager rather than for me, and they vary by manufacturer and by system release. Ask specifically whether the call event record includes an encryption or protected indicator per call, ask what the retention period is, and ask who has the account rights to run the report, because on a shared regional or statewide system the answer is often that the county radio manager can get it but has never asked. If you are on a hosted or shared system, the request may need to go through the system’s governance body, and that request is worth making in writing so there is a record of the answer.

Read the results carefully, because the raw count overstates and understates in predictable ways. Talkgroups programmed twice, once clear strapped and once secure strapped in the pattern Indiana recommends, will show clear calls that are entirely correct. Radio shop test transmissions, console announcements and mutual aid units operating under a documented exception all show up the same way. Sorting by radio ID rather than reading chronologically is what makes the report useful, since a genuine configuration failure concentrates in a handful of unit IDs that generate clear traffic consistently, while an accidental switch bump appears as one or two calls from a radio that is otherwise clean. Take the concentrated ones first, pull those radios, and check the talkgroup’s encryption state in the codeplug, the keys actually loaded, the date of the last programming, and the date of the last rekey.

Conventional systems do not give you this, since there is no controller writing call events, and the substitute is periodic monitored listening on your own talkgroups by an authorized person plus whatever your logging recorder captures. Ask your recorder vendor whether the encryption state of each transmission is captured as metadata on the recording, because a clear transmission that was decrypted at the console and a clear transmission that was never encrypted sound identical in the archive and the difference lives only in the metadata if it lives anywhere. This applies to your own system and your own traffic only, and nothing here extends to monitoring another agency’s communications.

The audit is worth doing on a schedule rather than once, and monthly is a reasonable cadence for most agencies because it is short enough that a bad codeplug push gets caught within weeks rather than after somebody outside the agency notices. The finished product is one number on an existing agenda, which is the count of clear transmissions on secure talkgroups for the month with the radio IDs attached, reported to whichever standing meeting already reviews communications issues. Nobody needs a new committee for this, and a line item that has read zero for six months and then does not is the signal you built the process to catch.

What the SOP has to say

Start with what a member does when a clear transmission happens on a secure talkgroup, since that is the moment the policy is actually used. The SOP should say that the person who hears it announces the condition on the talkgroup in plain language, that sensitive content stops immediately and moves to a resource known to be secure or to telephone, that the traffic already sent is treated as compromised for purposes of whatever operation is running, and that a supervisor is notified during the shift rather than at the end of it. The radio suspected of transmitting clear comes out of service to the radio shop, and somebody writes down the unit ID, the talkgroup and the time so the shop is troubleshooting a specific event rather than a rumor.

Key management needs one named owner, not a department. The CISA and SAFECOM operational best practices document on encryption key management published in August 2020 describes a county EMS example in which key management was assigned to the sheriff’s department, which determines which keys will be used and sets the over-the-air rekeying schedule for all radios on the system, and that concentration of authority is the point of the example. Whoever holds that role on your system owns the key inventory, the storage location number assignments, the rekey calendar and the authority to say no to a partner agency that wants a key. The same body of CISA guidance recommends adopting a standardized storage location number plan to reduce conflicts, which matters most for agencies that share keys across jurisdictions.

On the rekey schedule itself, the honest answer is that the interval has to come from what your system supports and what your governance body has adopted, and I am not going to publish a number as though a standard specified one. What the vendor and federal guidance consistently emphasizes is rotation rather than static keys, and responsiveness to lost or stolen radios, which the Tait presentation to APCO on P25 encryption management lists alongside scheduled key updates as a benefit of having a working key management facility. The compromise-driven rekey is the one that matters operationally, so your SOP needs a named person reachable at all hours who can order a radio inhibited and a key changed when a portable goes missing, and it needs the time target for doing it written down.

The rest of the policy is short. Spare, cache and loaner radios get keyed on the same cycle as in-service radios against a written inventory, and the person who signs a radio out signs that it was verified secure on the talkgroups it is going to use. Interop patches involving an encrypted resource may be created only by named roles, are announced on the encrypted talkgroup, are logged, and carry a teardown condition. Call detail records for secure talkgroups are audited on a stated cadence by a named role, and the result goes to a standing meeting. Every one of those sentences fits into a communications SOP you already have, and none of them requires buying anything.

What to do at your agency

• Have your radio manager or system administrator run a call detail record report for the last thirty days on every talkgroup your agency considers secure, filtered for clear transmissions, and bring the count and the list of radio IDs to the next communications or operations meeting already on the calendar.
• Ask your system administrator in writing this month whether the call event records on your system include a per-call encryption indicator, how long those records are retained, and which of your staff have the account rights to run the report, and file the answer with your communications SOP.
• Pull one spare radio and one in-service radio and run a supervised test on a sensitive talkgroup that establishes three things: whether the talkgroup is strapped or selectable, what a receiving radio does with a clear transmission on it, and what a radio with no valid key does when it tries to key up, then write the results and the firmware version into your programming documentation.
• Add a required post-programming verification step with a signature line to your codeplug procedure, so that no batch of radios goes back into service after a push or a rekey until two of them have been keyed up on the affected secure talkgroup and confirmed encrypted by a third radio and a console position.
• Have the dispatch supervisor confirm with your console vendor what clear and secure mismatch alerting the positions actually have, whether it is turned on, and where it appears on the screen, then brief the telecommunicators on what the indication looks like and who they tell.
• Write the patch rule into the dispatch SOP this month: name the roles who may create a patch involving an encrypted resource, require the patch be announced on the encrypted talkgroup, require it to be logged, and require a teardown condition recorded at creation.
• Have whoever owns your radio cache inventory every spare, cache and loaner radio against the key inventory, key the ones that missed the last rekey, and report the number of radios that were found unkeyed to the same meeting that gets the audit result.

Takeaways

• Encryption on P25 and DMR is applied by the transmitting radio on each transmission, so a talkgroup is only as secure as the worst-programmed radio affiliated to it, and the infrastructure will not reject or flag a clear transmission on a secure talkgroup.
• The 2011 USENIX Security paper by Sandy Clark, Matt Blaze and their co-authors reported that sensitive federal law enforcement traffic captured over two years in several United States metropolitan areas was routinely sent in the clear despite the users apparently believing it was encrypted, which documents that this failure is real rather than theoretical.
• Talkgroups in a codeplug are clear, selectable or strapped secure, and published statewide guidance from Indiana recommends strapping sensitive talkgroups secure and programming a talkgroup twice, once clear and once secure, when it genuinely needs both modes.
• Whether a receiving radio plays or mutes clear audio on a secure talkgroup is a policy decision with an officer safety consequence either way, the naming and defaults vary by vendor and configuration, and the behavior on your fleet should be tested and documented rather than assumed.
• What a radio does with no valid key varies enough by vendor and configuration that it must be tested on your own equipment and confirmed with your vendor, and Michigan’s published guidance notes that without infinite key retention selected a radio loses its keys when power is removed.
• Codeplug pushes, console positions and console patches each leak without any indication to the field user, and the Iowa statewide patching guidance states directly that a soft patch is created with no notice to the users whose traffic it moves.
• DMR basic privacy is a scrambler and analog voice inversion is not encryption, while the DHS Office for Interoperability and Compatibility states that the P25 standard encryption algorithm is AES 256 as defined in TIA-102.AAAD-B, and every radio in a group must carry the same algorithm before keys can be loaded at all.
• The single most useful control is a monthly count of clear transmissions on secure talkgroups pulled from call detail records, sorted by radio ID and reported to a meeting that already exists, because the icons and warning tones on the radio stop being noticed by users within about a week.