P25 Security Mitigation Guide
Matt Blaze, Sandy Clark, Travis Goodspeed, Perry Metzger, Zachary Wasserman, Kevin Xu
University of Pennsylvania 10 August 2011
In a recent research paper [pdf], we analyzed the security features of the APCO Project 25 (P25) digital two-way radio system. P25 radios are widely deployed in the United States and elsewhere by state, local and federal agencies, first responders, and other public safety organizations. The P25 security features, in which voice traffic can be encrypted with a secret key to frustrate unauthorized eavesdropping, are used to protect sensitive communications in surveillance and other tactical law enforcement, military and national security operations. Because radio signals are inherently easy to detect and intercept, encryption is the primary mechanism used to secure sensitive P25 traffic.
Our analysis found significant -- and exploitable -- security deficiencies in the P25 standard and in the products that implement it. These weaknesses, which apply even when encryption is properly configured, leak data about the identity of transmitting radios, enable active tracking and direction finding of idle (non-transmitting) users, allow highly efficient (low-energy) malicious jamming and denial of service, and permit injection of unauthenticated traffic into secured channels. Unfortunately, many of these vulnerabilities result from basic design flaws in the P25 protocols and products, and, until the standard is changed and products are upgraded, cannot be effectively defended against by end users or P25 system administrators. While we are unaware of incidents of criminals carrying out the active attacks we discovered, the hardware resources required to conduct them are relatively modest. As technology advances, these attacks will demand increasingly fewer resources and less sophistication to carry out.
However, in addition to active attacks against P25, we also discovered a serious practical problem that can be exploited easily today against fielded P25 systems: a significant fraction of sensitive traffic that users believe is encrypted is actually being sent in the clear. In the metropolitan areas we sampled, we intercepted literally thousands of unintended clear transmissions each day, often revealing highly sensitive tactical, operational, and investigative data. In every tactical system we monitored, encryption was available and enabled in the radios' configurations (and, indeed, was used correctly for the majority of traffic). Yet among the encrypted traffic were numerous sensitive transmissions sent in the clear, without their users' apparent knowledge. Virtually every agency using P25 security features appears to suffer from frequent unintended clear transmission, including federal law enforcement and security agencies that conduct operations against sophisticated adversaries.
This unintended clear sensitive traffic can be monitored easily by anyone in radio range, including surveillance targets and other adversaries, using only readily available, inexpensive, unmodified off-the-shelf equipment, including many of the latest generation of "scanner" radios aimed at the hobby market. Unintended cleartext therefore represents a serious practical threat to communications security for agencies that rely on P25 encryption.
P25 Encryption Usability Deficiencies
As noted in our paper, we found two distinct causes for unintended sensitive cleartext in federal P25 systems, each accounting for about half the clear transmissions we intercepted:
Fortunately, although the default configuration of most P25 radios exacerbates these problems, P25 system administrators can configure radios and adjust keying practices to mitigate these problems and reduce the incidence of unintended clear transmission of sensitive traffic in their systems.
Configuring P25 Systems for More Reliable Security
The user interfaces of most P25 radios are highly configurable by an agency's radio technicians, through the use of "customer programming" software provided by the manufacturer. We found it to be possible to configure existing P25 radios to have much more reliable security behavior, with better feedback to the user and more intuitive operation, than the default configuration provides. We recommend that encrypted radios used in tactical law enforcement operations be configured according to the guidelines in this section.
We use the Motorola Astro25 radios (e.g., the XTL-5000 mobile radio and the XTS-5000 portable) for terminology and illustration. Most other vendors' P25 radios have similar configuration capabilities, but they may use different terminology from Motorola's for the configurable features; contact your radio vendor for specific information on how to accomplish a particular configuration.
1. Disable the "Secure" Switch
The behavior of the "secure" switch is a source of confusion among even trained users. Aside from its obscure labeling (a zero for clear mode and a zero with a slash for encrypted mode), it is often out of view, can change position if touched, and does not provide direct feedback tied to the objective of communicating.
Instead, we recommend that encryption be a permanently enabled or disabled function of the selected channel. That is, if an agency has a frequency called Tac1 in which both encrypted and clear communication take place, radios should be configured with two Tac1 channels, one with encryption always enabled and the other with encryption always disabled. The two channel names (as displayed on the radio screen) should reflect this, e.g., Tac1 Secure and Tac1 Clear.
On the Motorola Astro25 radios, the secure/clear switch can be disabled in the "Radio Configuration" menu under "switches"; set the switch's function to "blank". Channels can then be "strapped" for "clear" or "secure" mode in the "Personality" menu for the channel.
2. Prevent Mixed Encrypted/Clear Communication with Separate NACs
Current P25 radios do not tie the decryption behavior of their receiver to the encryption behavior of their transmitter. That is, as long as a receiving radio has the correct key loaded, it will decrypt and play all incoming encrypted transmissions it receives on the current channel, even if it is itself set to transmit in clear mode. Similarly, even if a radio is set to transmit in encrypted mode, it will still receive clear transmissions on the current channel. This behavior runs counter to many users' expectations, and means that if a user in an encrypted network has his or her encryption switch in the wrong position, communication still occurs as if it were encrypted. The error is thus unlikely to be detected. (Some radios can be configured with a cleartext "beep" warning, but we found it to be ineffective at actually alerting users).
Acceptance of received clear traffic in encrypted mode and received encrypted traffic in clear mode is a basic feature of the P25 architecture; it cannot be disabled through most radios' configuration software. However, it is possible to use P25's Network Access Code (NAC) mechanism to segregate encrypted and clear traffic and achieve close to the same the same result. (NACs are the P25 equivalent of the sub-audible CTCSS tones used in analog FM systems.) P25 signals always include a 12-bit NAC code; P25 receivers can be configured to mute received transmissions that do not carry the correct code.
To prevent encrypted users from receiving clear traffic (and vice-versa), simply configure different NACs on the clear and encrypted versions of each channel. That is, Tac1 Clear might use a NAC code of "A01", while the Tac1 Secure version of the channel could use NAC code "A02". Even though both channels use the same frequency, users set to the encrypted version of the channel will not hear the transmissions of those on the clear version, nor will users on the clear channel hear the encrypted transmissions, even if they have the correct keys.
This configuration prevents the (common) scenario where a single user accidentally repeatedly transmits in the clear as part of an otherwise encrypted group. Communication simply cannot occur until all users are set to either encrypted or clear mode. (Note that this configuration prevents only accident, not malice. An attacker can still transmit clear traffic with the "encrypted" NAC to inject false messages).
The disadvantage of segregating clear and encrypted traffic on separate NACs is that, in an emergency, it may be more difficult for an unkeyed user to communicate with encrypted radios. But the behavior of radios configured in this way is ultimately much more intuitive, making the "encrypted" or "clear" mode a more reliable indicator of the state of the receiver as well as of the transmitter.
On conventional Motorola Astro25 radios, the transmit and receive NAC codes are set in the "Zone Channel Assignment" menu. Any repeaters must also be configured to accept both NACs (or to operate in transparent mode). Note that the multiple NAC approach will not work in trunked P25 systems; these systems can segregate encrypted and clear traffic by placing them in different "talk groups".
3. Use Long-Term, Non-Volatile Keys
Many federal systems use the P25 "OTAR" protocol to manage and distribute keys. For a variety of reasons, this protocol is unreliable in practice. The result is that users frequently do not have current keys, and are unable to successfully rekey. When users without key material must communicate with a group, the only option is for the entire operation to switch to the clear. That is, attempting to centrally manage keys via OTAR has the effect of forcing many sensitive operations to use clear mode.
Exacerbating the situation is the practice of using short-lived, volatile keys that are changed frequently (monthly or even weekly). This practice has its origin in military operations, where keyed radios are occasionally captured by enemy forces. (Once the network re-keys, captured radios become useless). But captured radios are not a significant threat in the law enforcement tactical environment. Here, the practice of re-keying results in less security, not more, especially given the unreliability of P25 OTAR systems.
Rather than short-lived keys refreshed via OTAR, we strongly recommend that agencies simply load a small set of semi-permanent keys into all radios used for sensitive communication. These keys should be changed (and radios re-keyed) only in the (rare) event that a radio is discovered to be lost or stolen. (Even in the unlikely case that a radio is stolen and not detected, a system with long-lived keys is still more secure with a small number of compromised radios than a system using an unreliable keying scheme that frequently forces users to operate in the clear).
Note that radios configured for "volatile" keying can lose their key material if their battery is disconnected and under certain other conditions. When this happens, radios can only operate in the clear until they are re-keyed. To prevent accidental key erasure, we recommend that Motorola Astro25 radios be configured for "Infinite Key Retention" in the "Security" menu of the programming software. We also suggest that provisions be made for deploying keyloading devices in the field to quickly re-key radios if keys are accidentally deleted.
For further information, see our paper [pdf].
The configuration changes here are intended to address only one (albeit perhaps the most immediate and serious) of the P25 security vulnerabilities that we discovered -- that of unintentional transmission of sensitive cleartext. However, we emphasize that configuring radios as we recommend does not prevent other attacks we discovered (such as low-energy jamming or active tracking). Until these problems are addressed in the standard and new products implemented, we urge agencies that use P25 for sensitive traffic, in addition to configuring radios as we recommend here, to not regard P25 communication as reliably secure against modestly sophisticated adversaries.
We have made the federal tactical and public safety radio community aware of the attacks we discovered and of the problem of unintended cleartext, but it is possible that some sensitive P25 users are not yet aware of the risks and mitigations that are possible. While we cannot provide extensive consulting services, we are happy to discuss specific issues and mitigation strategies with agencies whose communication may be at risk.
Contact the University of Pennsylvania P25 Security Research Group via email, blaze (atsign) cis.upenn.edu .
Partial support for this work was provided by a grant from the National Science Foundation, CNS-0905434. All views are those of the authors.