Privacy

Privacy

Although all six radios are on the same channel and talkgroup, only A-E can communicate with Privacy since F has no Key provisioned. A can talk to D with Privacy since they share the same key. Similarly, B; C; D and E can communicate since they also share the same key but can only communicate with A and D in clear (without Privacy) mode because their keys are different.

Privacy is a digital feature in MOTOTRBO radios that encrypt voice and data packets making it difficult or even impossible for unauthorized parties to monitor a users communications. Radios that need to communicate with each other need to be programmed with one or more shared keys - that is a key (numeric value) must be the same in all participant radios. Radios which are not supposed to monitor this communication can either be configured with no keys or different (non-matching) keys.

Privacy in DMR is different from encryption in TETRA or P25 in that it is effectively end-to-end. Only the radios (and dispatch application if used) contain the keys - all other infrastructure does not know what the key is. Also MOTOTRBO only uses payload encryption which means that headers (e.g. source and destination radio ID) and control messages (e.g. radio disable and enable) are sent clear. Customers who have concerns about unencrypted control messages should consider implementing the Authenticated Radio Disable and TX Disable features.

Analogue Scrambling

Some MOTOTRBO radios also support analogue scrambling. This feature is also known as frequency inversion scrambling and offers a comparatively basic means of protection for voice.

When a radio transmits with analogue scrambling enabled, the users voice is used to modulate a +-3kHz tone. The resultant audio sounds garbled on a receiver without this feature enabled. It can only be hard on a radio with this feature turned on. Since the feature is widely known and implemented, it can interoperate with other frequency inversion products from other vendors.

Voice and Data Privacy in Digital Mode

Over a digital channel, MOTOTRBO supports a way to keep communication (both voice and data) private. Privacy protects the information, where “protection” means that the MOTOTRBO resists reading of data payload or listening of voice by anybody other than the intended receivers. Only MOTOTRBO Capacity Max provides a mechanism to authenticate the radios or radio users.

Types of Privacy

By default, all MOTOTRBO radios support Basic and Enhanced privacy. Advanced Encryption Standard (AES) is an optional feature in certain models. Basic Privacy utilizes Motorola Solutions proprietary mechanisms and algorithms and therefore is not interoperable with privacy offerings from other vendors. AES Privacy is licensed in the radio requiring a CfS license. AES and Enhanced Privacy can be utilized in all MOTOTRBO architectures.

The main difference between Basic Privacy, Enhanced Privacy, and AES Privacy are that Enhanced Privacy and AES privacy provide a higher level of protection and support multiple keys in a radio, compared with only one key in the case of Basic Privacy.

The main difference between Enhanced Privacy and AES Privacy are the algorithm utilized and their key size. Enhanced Privacy utilizes ARC4 algorithm with 40 bit keys, and AES Privacy utilizes the AES algorithm with 256 bit keys. AES Privacy has a higher level of protection in terms of algorithm than Enhanced Privacy.

The privacy types are not interoperable. Only one type can operate in each radio at any time. This implies that all digital private channels support either Basic Privacy or Enhanced Privacy, and that all radios on a repeater must use the same mode, even if they are in different groups. In direct mode, all radios that communicate with each other must use the same privacy mechanism. Enhanced Privacy and AES Privacy are interoperable with privacy offerings from other vendors.

AES Configuration in MOTOTRBO

The AES/Symmetric Key options are visible in the CPS only if the AES feature is purchased. The radio, repeater, and MNIS of a system require configuration for AES. In CPS, the radio codeplug lists all Symmetric Keys on the Privacy tab, under the AES heading. Privacy types None or Enhanced are independent from the Symmetric Keys configuration. Basic Privacy does not work with AES. If Basic Privacy is configured, the radio bypasses AES for the transmission even if Symmetric Keys are configured in the radio. The radio allows the privacy type selection of None or Enhanced to be configured with or without Symmetric Keys. Only one privacy type is allowed on each radio channel. The radio allows up to 16 different Symmetric Keys to be configured. Each Symmetric Key can be up to 256 bits in length.

To support AES, the repeater codeplug must be configured with Enhanced Privacy type since the repeater does not encrypt or decrypt any AES payload. The Enhanced Privacy option allows the repeater to repeat the AES and Enhanced Privacy encrypted audio and data bursts. For proper functioning of the repeater in a system with AES encrypted transmissions, the repeater must be running on firmware version R02.30.00 or later. A radio can be configured with both Enhanced Privacy keys and Symmetric Keys. The radio can receive audio and data calls encrypted with AES or Enhanced Privacy keys, from any talkgroup in the RX Talkgroup list that is tied to a personality, as long as the same key and privacy type of the transmitting radio is selected in the personality.

CPS/RM can be used to pre-configure and manage the Symmetric Keys. Optionally OTAR can be used to update the key in existing encrypted radios.

AES uses the Symmetric Keys as encryption keys. The MNIS require Symmetric Keys configuration for AES encryption. The MNIS allows up to 255 Symmetric Keys.

Strength of the Protection Mechanism

Basic, Enhanced, and AES privacy types protect confidentiality of the payload. The protection mechanisms described in this section require a key that is shared only among the intended parties. The resistance provided by Basic Privacy is minimal for the following reasons:

• Basic Privacy uses a non-cryptographic algorithm to transform plain voice/data into protected voice/data. It is possible for an adversary to obtain the key by storing a few over-the-air voice or data packets and performing few simple mathematical operations.
• Basic Privacy uses 16-bit keys. A user selects a key from 255 predefined keys stored in the CPS. The limited number of possible keys makes it easy for an adversary to guess the key in-use. The intended use of the Basic Privacy is to stop casual eavesdropping only.

The resistance provided by Enhanced Privacy is significantly better than the resistance provided by Basic Privacy for the following reasons:

• Enhanced Privacy uses a cryptographic algorithm to transform plain voice/data into protected voice/data. The algorithm is the well-known Alleged RC4 (ARC4), and is same as RC4. A cryptographic algorithm makes it very difficult for an adversary to obtain the key from over-the-air protected messages.
• Enhanced Privacy uses 40-bit long keys. A radio can store up to 16 keys and the Enhanced Privacy allows using different keys for different channels. The large number of possible keys (approximately 1 trillion) makes it difficult for an adversary to guess the value of a key. Note that a 40-bit long key may not provide the protection needed to transmit valuable data such as credit card numbers.

• Using the same key, the Enhanced Privacy protects each superframe of voice or each data packet in a different and unrelated way. This increases the resistance further.

The resistance provided by the AES is significantly better than the resistance provided by Enhanced Privacy for the following reasons:

• A cryptographic algorithm is used to transform plain voice/data into protected voice/data. The AES has been adopted by the United States government, and is now used worldwide.
• The AES uses 256-bit long keys. A radio can store up to 16 Symmetric Keys for AES privacy, and the radio configuration allows using different keys for different channels. The large number of possible keys makes it difficult for even sophisticated hackers to guess the key from the over-the-air interface.
• Using the same key, the AES protects each super frame of voice or each data packet in a different and unrelated method, which further increases the resistance.

Effects of Privacy Protection on Performance

Basic Privacy uses only one key, which is known to both the sender and the receiver. This eliminates the need to transport cryptographic parameters (for example, Key Identifier) with the voice or data payload. A voice message, in case of Basic Privacy, neither requires any modification in the payload nor any additional headers. Therefore, the System Access Time and the audio quality of a Basic privacy protected voice is same as that of an unprotected voice.

Enhanced Privacy and AES Privacy use multiple keys and a random number to ensure that the encryption data is different for each data message and each superframe of a voice message. This requires transporting cryptographic parameters (for example, Key Identifier, Initialization Vector) with the voice or data payload. A voice message, in the case of Enhanced and AES Privacy, requires an additional header and replaces some of the least important bits of the voice payload with the Initialization Vector. The additional header increases the System Access Time except when Talk Permit Tone is enabled (in repeater mode) where the additional header replaces one of the normal voice headers. The replacement of payload bits reduces the voice quality. Note that the reduction in voice quality is barely noticeable.

With Privacy, a data message requires an additional header to distinguish between an unprotected data message and a protected data message. In the case of Enhanced and AES Privacy, the additional header is also used to transport cryptographic parameter. This reduces the data throughput. For example, a typical protected confirmed location response takes 600 milliseconds compared to 540 milliseconds for an unprotected one (approximately 10% loss in throughput).

User Control Over Privacy

Customer Programming Software (CPS) allows a System Installer to select the type of privacy (that is, Basic Privacy or Enhanced Privacy or AES Privacy). CPS also allows the enabling or disabling of the privacy service of a channel. The option to toggle the privacy capability per channel can additionally be given to the radio user by providing a menu entry or programmable button. Without the menu entry or programmable button, the radio user is essentially “locked” to the channel’s privacy setting. It is important to note that a user can set or reset privacy for a channel, and not for the radio. If the user is provided with the menu entry or programmable button, and the user toggles the privacy setting, only the selected channel’s privacy setting is toggled and remains toggled even after the user changes channels or zones. Toggling the privacy setting on a channel will not affect the privacy setting on other channels.

The privacy setting of a channel controls the transmit privacy setting, not the receive privacy setting. A radio on a privacy-enabled channel always transmits protected, while a radio on a privacy-disabled channel always transmits unprotected. However, for the privacy reception, it is little bit different. It depends on whether “Ignore Rx Clear Voice/Packet Data” and “Fixed Privacy Key Decryption” options are enabled. See below.

Ignore RX Clear Voice/Packet Data and Fixed Privacy Key Decryption

In general, the radio receives and decodes both unprotected and protected message, regardless of the channel’s privacy setting. Also, when the radio receives a protected message, regardless of the channel's privacy setting, the radio always tries to unscramble or decrypt the message.

If a radio is never required to receive protected messages, then it should not be provisioned with keys or should be provisioned with a key that is different from the key(s) used by the rest of the system. Simply setting a channel to be privacy-disabled does not stop the radio from receiving protected messages. A radio receives a protected message correctly as long as it has the right key. Therefore, when one radio user on a privacy-enabled channel transmits, every radio, regardless of its channel’s privacy-enabled or privacy-disabled status hears the transmission clearly if their provisioned Privacy Key is identical to that of the transmitting radio. A radio user receiving a protected transmission sees the green LED blinking rapidly. The receiving radio user should consider changing the privacy setting to match that of the call initiator when replying.

In Basic Privacy, a system utilizes only one key and if all radios are privacy capable, it is recommended that all radios are set to privacy enabled and equipped without the option to toggle the privacy settings by a radio user. Since Basic Privacy does not cause any degradation in audio quality, or decrease in performance, there is no reason for the normal user to switch between non-privacy and privacy.

Removing the option to toggle the setting from the radio user safeguards against any complicated privacy mismatch scenarios. The following configurable options for reception are available within CPS and the Radio Management (RM) application.

Ignore RX Clear Voice or Packet Data

The “Ignore RX Clear Voice or Packet Data” option determines how the radio handles the reception of unprotected (clear) calls while configured for privacy. If a radio receives an unprotected (clear) call while configured for no privacy, then it decodes the call normally. If a radio receives an unprotected call while configured for Basic, Enhanced, or AES Privacy, and the “Ignore Rx Clear Voice or Packet Data” option is unchecked on the selected personality, then it decodes the call normally. If a radio receives an unprotected call while configured for Basic, Enhanced, or AES Privacy, and the “Ignore Rx Clear Voice or Packet Data” option is checked on the selected personality, then it does not decode the call.

The “Ignore Rx Clear Voice or Packet Data” option per personality is not available if a radio is configured for No Privacy. When the “Ignore Clear Signal” option is enabled and the radio user disables privacy from the radio menu or a programmable button, the “Ignore Clear Signal” option does not apply, and the radio decodes unprotected (clear) calls normally.

Reception of Unprotected Calls with Ignore RX Clear Enabled/Disabled

Source Configuration	Target Configuration		Result
Privacy Type	Privacy Type	Ignore RX Clear
No Privacy	No Privacy	N/A	Decodes
No Privacy	Privacy	No	Decodes
No Privacy	Privacy	Yes	Does Not Decode

The “Ignore RX Clear Voice or Packet Data” option is useful if there is a concern that non-secure individuals may disrupt communication within a talkgroup.

While the “Ignore RX Clear Voice or Packet Data” option is checked, none of the voice/data call are decoded if they do not utilize privacy. “Ignore RX Clear Voice or Packet Data” can also be configured at a radio wide level within the Security folder in Radio Management. If selected in the radio's security configuration, all personalities in the radio have “Ignore Rx Clear Voice or Packet Data” enabled.

If “Ignore Rx Clear Voice or Packet Data” is not selected, then a “Clear Call Received” tone can be enabled. When this tone is enabled, the radio sounds a tone every five seconds when the radio is decoding an unprotected (clear) voice call.

Fixed Privacy Key Decryption Option

The “Fixed Privacy Key Decryption” option determines how the radio handles the reception of protected (encrypted) calls while configured for privacy.

If a radio receives a protected (encrypted) call, and the “Fixed Privacy Key Decryption” option is unchecked on the selected personality, and there is a matching key (with the same Key ID and Privacy Type) in its Key List, then it decodes the call. If there is no matching key, then it cannot decode the call.

If a radio receives a protected (encrypted) call, and the “Fixed Privacy Key Decryption” option is checked on the selected personality, and the received key (as indicated by Key ID and Privacy Type) matches the key (as indicated by Key ID and Privacy Type) of the configured Transmit Key for the selected personality, then it decodes the call. If the received key does not match the configured Transmit Key for the selected personality, then it does not decode the call, even if there is a matching key in the Key List. This feature has no effect for Basic Privacy, since only one key is used for both transmitting and receiving.

If the receiving radio is configured with No Privacy or the radio user disables privacy from the radio menu or a programmable button, and the “Fixed Privacy Key Decryption” is checked, then the radio transmits and receives unprotected (clear) calls and decodes protected calls if the received Key matches any Key in the Key List.

Reception of Protected Calls when Fixed Privacy Key is Enabled/Disabled

Source Configuration	Target Configuration	Received Key Match	Result
Privacy Type	Fixed Privacy Key Decryption
Enhanced or AES	No	Matches a Key in Key List	Decodes
Enhanced or AES	Yes	Matches the configured Key	Decodes
Enhanced or AES	Yes	Matches a Key in Key List	Does not Decode
Enhanced or AES	N/A	Does not match a Key in Key List	Does not Decode

The “Fixed Privacy Key Decryption” option is useful if there is a need that a radio user, once on the selected personality, does not want to be disrupted by other communications. For example, if a group of radio users want to have the capability of focusing on the protected communication among them when some event occurs, a dedicated personality can be configured with the same Transmit Key and this option turned on. When such event occurs, they could move to that configured personality and focus on the communication among themselves and not to be disrupted.

When the “Fixed Privacy Key Decryption” option is checked, the voice/data calls are not decoded if the received key does not match the selected personality's Transmit Key. The ramifications of this could result in missed communications in some configurations.

If numerous radio configurations are utilizing the “Fixed Privacy Key Decryption” option, it implies that not all radio configurations share a common receive key. If radios do not share a common receive key, call types that utilize a single transmit key and are targeted towards many users, such as All call or Talkgroup Call may not be decoded by everyone. Similarly, since the MNIS Data Gateway utilizes a single transmit key, data calls from a data application to the radios may not be decoded by everyone. In addition, if utilizing a talkgroup receive list, only talkgroup calls that utilize the same key as the selected personality's Transmit Key are decoded. Only individual calls that utilize the same key as the selected personality's Transmit Key are decoded. All this should be considered when utilizing the “Fixed Privacy Key Decryption” option.

“Fixed Privacy Key Decryption” can also be configured at a radio wide level within the Security folder in Radio Management. If selected in the radio's security configuration, all personalities in the radio have “Fixed Privacy Key Decryption” enabled.

Privacy Indications to User

It is important for a radio user to know the privacy status (that is, enabled or disabled) of the current channel, and also to know if the received voice transmission is unprotected or a protected voice transmission. There is no privacy indication for incoming protected data transmissions. Prior to transmitting, a radio user should check the privacy setting of the current channel. On privacy enabled channels, an icon is shown on the front panel display of the radio when the radio is idle.

Privacy Status/Type	Icon
Enabled
Enhanced and Disabled
None	(none)

Upon receiving a voice transmission, the radio user can know the privacy status of the voice transmission by observing the blinking rate of the receive LED. When receiving a protected voice transmission, the LED blinks green but at a quicker rate than when receiving an unprotected voice transmission.

If radio users in a call have mismatching privacy settings, but the same key, they are able to communicate, but the transmissions are protected in only one direction. In other words, only the transmissions from radios with privacy enabled are protected. The radio does not automatically negotiate privacy settings, or block transmissions that are not protected. Therefore, it is up to the radio users to monitor the privacy indications to determine if all the users in the call have a matched privacy setting. The radio displays the privacy setting of the received transmission, but blinks if it does not match the transmit mode of the receiving radio. When a privacy setting mismatch occurs, they should request the other members of the call to switch their privacy settings to match. The radio allows users to enable or disable privacy on the channel while on a call.

Radio users with non-display or numeric display radio models are not able to view the icon that is shown on a privacy-enabled channel. Therefore, it is recommended that such users should not have the option to toggle the privacy setting. If non-display or numeric display radio users must be able to toggle between protected and unprotected, it is recommended that this be done by programming duplicate channels, one with privacy enabled and one without, and the user should use the dial position to toggle between protected channels and unprotected channels. For example, dial position one may be set to communicate with a Group in unprotected mode, and dial position two may be set to communicate with the same group but in protected mode.

Key Mismatch

In the case of Basic Privacy, a receiving radio assumes that the received protected transmission is protected using the same Key that it has, because the key identifier is not sent with the message.

If the receiving radio does not have the same key as the transmitting radio, the receiving radio cannot decode the transmission correctly. For voice transmissions, this results in unintelligible audio - sometimes referred to as digital warbles, being played through the target’s speaker. For data transmissions, this results in an unsuccessful data message transmission. This is because the IP/UDP headers of a data message when unprotected using a wrong key fail to CRC check. On failure of the checksum, the data message is not delivered to the application.

In the case of Enhanced and AES Privacy, the key identifier is sent with the message and if the receiving radio does not have the key then it either remains muted (in case of voice message) or discards the data message. If the key value associated with the key identifier is different in the sender and receiver, due to a miss-configuration, then the voice transmissions result in unintelligible audio and the data transmissions are unsuccessful.

Keys and Key Management

In the case of Basic Privacy, a radio is capable of holding only one Privacy Key. The same key is used to protect and unprotect voice and data transmissions over all the channels and for all call types: Group Call, Private Call, All Call, or Emergency Call.

In the case of Enhanced Privacy, a radio is capable of holding up to sixteen Privacy Keys, where keys are associated with channels. In the case of AES, a radio is capable of holding up to sixteen Symmetric Keys, where each key is associated with channels.The relationship between keys and channels is 1:0...n. (in other words 1 to 0 or 1 to many) “0” means that keys may be provisioned into the radio but are not associated with any channel. In this case, the keys are used to decode a received message but are not used by the radio to encode a transmission.

A Privacy Key is provisioned in a radio using the CPS/RM or a KMF. The keys are not readable, editable, or erasable by the radio user. Once a key has been chosen and programmed into a radio, the key cannot be extracted and viewed by CPS. It can only be retained or overwritten. In the case of Basic Privacy, a CPS user can select one of the 255 prescribed keys. These keys are referenced by a key index from 1 to 255. Each key index references a particular 16-bit key that is used for protecting over-the-air. There is no option for a “blank”, “null”, or “zero” key. In the case of Enhanced Privacy, the valid range for the value of a key is 1 to 1.099.511.627.774₁₀ (FFFFFFFFFE₁₆). The key values 0₁₀ and 1.099.511.627.775₁₀ (FFFFFFFFFF₁₆) are reserved and should not be used.

In the case of AES, the valid range for the value of a key is 1 to 1.15×10⁷⁷ (FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF₁₆).

The following details of this key management section is only applicable when the OTAP feature is not purchased or not available in the system. If OTAP is present, refer to the OTAP sections on updating the privacy type and the keys.

MOTOTRBO does not support remote or over-the-air programming of keys into a radio. For a system without the OTAP feature, the encryption keys can be programmed in a radio using only CPS. Keys can be programmed in a radio using only CPS. CPS supports loading of the value and identifier of a key into a radio either manually, or from the RM, or from a protected archive file (in case of Enhanced Privacy only). In case of getting the keys from a protected archive file, the CPS User selects the protected file and provides the password. The file is unreadable without a password. The CPS is capable of copying key(s) from one radio's archive into another radio's archive without the user needing to retype the key for each radio.

A customer may need to change one or more keys (in the case of Enhanced and AES Privacy) with a set of new keys into a set of radios. Some of the reasons for changing keys are:

• Compromise of keys
• Security policy of the customer requires periodic update of keys
• Loss of a radio resulting in a concern that this may lead to compromise of keys or eavesdropping.

The lowest-cost way to implement a key switchover, is to gather all radios and re-program them together at the same time. But it may not always be possible to gather all the radios without seriously affecting day-to-day operations.

An alternate method is to use Radio Management. This requires that the Control Station or MNIS be first provisioned with the new key(s). See below.

The third alternative would be to use a KMF and make use of OTAR.

Multiple Keys in a Basic Privacy System

Although a radio can only use one key in a Basic privacy system at a time, a Basic privacy system may utilize multiple keys to sub-divide a group into a set of groups. Note that this is not a recommended configuration, and some considerations need to taken into account, if the decision is made to utilize multiple keys in a system.

It is not recommended that Groups be sub-divided into smaller groups with the use of keys. This results in one sub-group of users hearing unintelligible audio (or digital warbles) when the other subgroup communicates. It is recommended that the users should be divided into Groups, and provisioned so that a user can not transmit nor receive on another Group. If users with different keys are allowed to communicate with Basic privacy enabled, for example through a protected Private Call, a key mismatch occurs and unintelligible audio is heard. Although these users with different keys are never able to communicate privately, they are able to communicate when privacy is disabled.

For example, two different Groups are isolated by provisioning different privacy keys. When a user in each Group needs to communicate to each other through a Private Call, they must do it with privacy disabled. If a radio user needs to communicate with both Groups through an All Call, the radio user must transmit in clear mode so that both Groups can monitor. If users respond with privacy-enabled, the user who initiated the All Call only monitors the responses protected with a matching key.

If the system is utilizing data applications and must communicate through a control station to the application server, all radios on a slot must have the same key or they are not all able to properly communicate with the control station. For similar reasons, it is not recommended to have radios without privacy capability, like the older software versions, in the same Group as radios with privacy capability. Since older radios are not provisioned with a Privacy Key, the audio is muted. If radios with privacy capability need to communicate to radios without privacy capability, they must disable privacy before transmitting.

As a general rule, it is always recommended that groups with different privacy capabilities and settings be placed in different Groups and on different slots.

Data Gateway Privacy Settings

The privacy setting of a control station acting as the data gateway to the application server is very important for consistent data communications. This may even drive the privacy configuration of the rest of the system.

If a system contains some privacy-capable radios and some privacy-incapable (older software versions), radios then the control station must be privacy capable, but configured to transmit in clear mode. This way, outbound messages can be received and processed by the older radios (not privacy capable). Note that the privacy capable radios send their data protected and the control station will be able to decode these messages, as long as it has the proper key.

In case of Basic Privacy, there can only be one key per channel (or slot). Since the control station can only contain one key, it cannot communicate protected to two different Groups utilizing different keys. If a Basic Privacy system utilizes multiple keys, those users must be divided onto two separate channels (or slots), each with their own control station utilizing the proper key. Setting the control station to privacy disabled does not solve this problem since incoming messages such as GPS or text messages may be protected using different keys and only one key can be used at the control station to decode. Therefore, although outbound messages would be functional, inbound messages would not be.

If users have the ability to toggle their privacy settings, it is acceptable to have the control station set to either privacy enabled or privacy disabled, but only if their provisioned keys match. If the control station is set to privacy enabled, and the radio is set to privacy disabled, one direction of the data communication is protected and the other is unprotected. Since radios set to privacy disabled receive protected, and radios set to privacy enabled receive unprotected, the communication path works. If important data is being transferred to and from the fixed infrastructure, it is recommended that the control station should be set to “protected”. This guarantees that at least half of the data transmission is private. Also, the system is tolerant if fielded radios are set to privacy disabled.

It is recommended that all radios including control station should have same privacy settings. If the privacy setting is Enhanced and/or AES Privacy, then the control station should have the transmit keys of all the radios and all the radios should have the transmit key of the control station.

Protecting One Group's Communications from Another Group

There may be a need for one group’s voice and data to be protected against another group over the same channel (same frequency and same slot). There may be some radio users who are members of one or more of the groups. In this case, if a group not only wants to protect their communication from intruders but also from other groups then each group should use separate keys for protection.

The System Installer should make each group that need to be protected as “TX Group” for a personality. The relationship between a personality and a group is 1:1. The System Installer should associate a key to a personality. The relationship between a key and a personality is 1:1. And therefore the relationship between a key and a group becomes 1:1. If a radio ‘X’ wants to make a protected Private Call to a radio ‘Y’ and if both the radios are member of a group ‘T’ then the radio ‘X’ goes to a personality whose “TX Group” is ‘T’. If there is no group where both the radios are member then it is not possible to send a protected message.

For a protected “All Call”, the transmitting radio should go to a specific personality and the key associated with that personality is present in all the radios. For a protected Private Call, the transmitting radio should go to a specific personality and the key associated with that personality is present in the receiving radio

Updating the Privacy Type

It may not be possible for a System Installer to update all the radios from Basic Privacy to Enhanced Privacy and/or AES in one session for a system where OTAP is not available. In such cases, the System Installer instructs all the radio users to disable the privacy feature and operate in clear mode. When instructed, the radio users disable the privacy feature using the radio front panel. All the messages are transmitted in clear.

The System Installer updates the software of radios and configures the radios for desired privacy (Enhanced Privacy and/or AES). Once all the radios are upgraded, the System Installer updates the software of repeaters and configures them for Enhanced Privacy. The repeaters require Enhanced Privacy configuration for AES.The control stations acting as the data gateway should also be upgraded.

The System Installer instructs all the radio users to enable the desired privacy feature. The radio users enable the desired privacy feature using the radio front panel. The control stations also enable the desired privacy. All the messages are transmitted using the desired privacy setting.