Authentication & Voice Privacy

1xBTS checks handset credentials with CAVE authentication and can enable voice privacy on authenticated calls. Provision the subscriber’s A-key and check results on the subscriber or mobile page.

Authentication defaults to monitor: checks run when the cell requests authentication, but failures do not deny service. Enforce rejects failed authentication, with the provisioning and SSD recovery exceptions described below. OTASP A-key generation is a separate opt-in and is disabled by default.

Configure authentication

The defaults are authentication.mode: "monitor" and authentication.voice_privacy: "optional". No configuration override is needed for these values. Set options in config/msc.local.json when different behavior is required.

Restart the MSC after changing its configuration. For a combined stack, restart cdma-nib.

Monitor mode also runs configured SSD updates, per-call challenges, and COUNT updates on eligible calls. It can change the handset’s shared secret data and call history count.

For the software BTS, ensure overhead.auth_mode is not overridden. Broadcast authentication is managed by authentication.mode.

Femtocells

CAVE authentication, OTASP A-key generation, and voice privacy have not been tested with femtocells. See Femtocell Setup.

Provision the subscriber

In Subscribers, add the handset’s IMSI and ESN or MEID. The Authentication card manages credentials for the subscriber’s primary identity. See Identity & Addressing for subscriber matching and MEID discovery.

Choose either manual entry or OTASP generation. Both establish an A-key shared by the handset and HLR. A network-side key entry does not program the handset.

Option 1: Enter an A-key manually

The A-key check digit calculator can generate an A-key and its ESN-specific check digits for manual handset entry, typically on IS-95 devices. It also verifies an existing 26-digit entry.

1. Program the A-key on the handset using its supported service programming procedure.
2. Open the subscriber’s Authentication card and select an entry format.
3. Enter the same key and select Set A-key.
4. Place a call. With the default SSD update policy, the network establishes shared secret data when needed.
5. Confirm successful authentication and SSD: Established in the dashboard.

Keypad entry requires an ESN on the primary identity. An IMSI+MEID identity without a stored ESN can use hex entry.

Setting an A-key clears stored SSD. Clear removes the network’s A-key and SSD, but does not erase the handset’s key.

Option 2: Generate an A-key with OTASP

The handset must support OTASP key generation and have a matching subscriber identity. Configure its Service Programming Code as described in OTASP.

Merge this into config/msc.local.json:

{
  "otasp": {
    "enabled": true,
    "writes": {
      "a_key": true
    }
  }
}

1. Restart the MSC or combined stack.
2. Dial *228 on the handset.
3. Open the session from Recent OTASP Sessions on the subscriber or mobile page.
4. Confirm that key generation, SSD update, re-authentication, and commit succeed.
5. Place a normal call and check its authentication result.

Other OTASP write flags remain independent. They do not need to be enabled to provision an A-key.

An A-key already on file is preserved, even if the call failed authentication. The session records why key generation was skipped. To replace a key, clear it in the subscriber’s Authentication card before starting a new OTASP session.

Key computation can take several seconds. The session viewer shows each step and the handset’s response time. If provisioning fails after the handset has computed its temporary key, the session ends without a commit so the handset does not save a key that the HLR lacks.

Enable enforcement

After confirming successful authentication, set authentication.mode to enforce and restart the MSC.

The default allow_unprovisioned: false refuses devices without CAVE credentials when authentication is requested. Setting it to true permits that case. It does not permit an incorrect signature from a provisioned device.

A handset with an A-key but no established SSD can register so that it can start a call to establish SSD. A call with a failed signature can proceed to recovery, but it connects only after SSD update and a per-call challenge succeed. An unauthenticated access-channel SMS does not use this recovery exception. OTASP for a subscriber with an A-key requires a valid signature under both monitor and enforce, as described in Access Control.

Enforcement depends on the cell requesting authentication. Leave the software-BTS override unset. Femtocell authentication has not been tested.

Configure voice privacy

Set authentication.voice_privacy in msc.local.json:

For example, to request privacy automatically:

{
  "authentication": {
    "voice_privacy": "always"
  }
}

Calls begin with privacy inactive. Activation follows successful per-call authentication. Calls without authenticated keys remain public. Voice privacy has not been tested with femtocells.

The dashboard shows a lock indicator on calls and privacy messages. Its tooltip distinguishes public, pending, and private status. Private-long-code voice privacy applies to the radio link, not to SIP/RTP or packet-data transport.

Check results

The subscriber’s Authentication card shows whether an A-key and SSD are established, COUNT, failures since the last success, and the last successful authentication time. Recent activity is also available on the mobile page.

The Message Log marks authentication with ✓ for success, ✗ for failure, and ! when service is allowed pending an SSD update. Open the result for details. Recent authentication activity is held by the MSC and resets when it restarts. An access for which authentication was not requested produces no authentication verdict.

The configuration reference lists all authentication settings.