CAVE 2G security comes to 1xBTS

1xBTS now supports CAVE authentication, A-key provisioning through OTASP, and voice privacy on authenticated calls.

CAVE (Cellular Authentication and Voice Encryption) is a second generation (2G) feature of CDMA, in the original IS-95 pre-CDMA 2000 standard. It provides the ability for the network to authenticate a handset’s access messages, perform ad-hoc challenges during traffic, and to use shared key material between the handset and the network to use a private long code mask.

How CAVE works

CAVE uses an A-key, a 64-bit secret stored by both the handset and the network. The A-key is used to generate Shared Secret Data, or SSD, which is what the handset and network use to calculate authentication responses. This allows SSD to be updated without having to program a new A-key into the handset.

The network broadcasts a random challenge, which the handset answers using its SSD, and authenticates the access if the response matches the value the network generates from the same inputs.

Once the handset is on a traffic channel, the network can perform an SSD update or send a unique challenge specifically to that handset. For example, after programming an A-key, the handset and network still need to establish matching SSD. We can do this during call setup, then use a unique challenge to check that they agree.

Getting started

Authentication defaults to monitor mode, which checks authentication but allows service if a check fails or no credentials are set on the subscriber record. This allows handsets to be provisioned and their credentials verified before enforcement is enabled. The other modes are off, which disables normal authentication checks, and enforce, which rejects unauthenticated access.

Voice privacy defaults to optional, which enables privacy when the handset requests it and authenticated call keys are available. It can also be set to never to keep calls public, or always to request privacy automatically on authenticated calls, subject to handset acceptance.

The Authentication & Voice Privacy guide explains how to change these options in config/msc.local.json. After making changes, restart 1xBTS.

Provisioning an A-key

An A-key can be provisioned over the air using OTASP or programmed manually into the handset and network.

OTASP A-key provisioning is disabled by default. Once enabled, dial *228 on a supported handset to generate a matching key on both sides, establish SSD, and re-authenticate before committing it. Provisioning can also be started from the subscriber or mobile page using Start provisioning.

For manual programming, the A-key check digit calculator can generate a key and its ESN-specific check digits. Program the handset with that key, then enter the same key in the subscriber’s Authentication card. The next call establishes SSD with the default settings.

The Authentication & Voice Privacy guide covers setup for both methods.

Enforcing authentication

Once handsets are provisioned and authenticating successfully, enable enforce mode to reject unauthenticated access. Devices without credentials are rejected by default, while OTASP remains available for provisioning.

With the default SSD update policy, a handset with an A-key set on the subscriber record can recover from a failed access signature through an SSD update and unique challenge. The call connects only after both succeed.

Authentication in the dashboard

The Message Log shows authentication status alongside the related messages. A check mark indicates success, a cross indicates failure, and an exclamation mark means service was allowed pending an SSD update. Hover over an indicator for details.

The subscriber and mobile pages show recent authentication activity, including A-key and SSD state on the subscriber’s Authentication card. OTASP session details show key generation, SSD update, and re-authentication as they happen. The dashboard guide explains the indicators in more detail.

Voice privacy

Voice privacy uses CAVE-derived key material to activate a private long code mask on authenticated voice calls. Calls begin with privacy inactive, and activation follows successful per-call authentication and handset acceptance. The voice privacy settings control when it is requested.

The dashboard’s lock indicator distinguishes public, pending, and private calls, so a privacy request can be distinguished from privacy that is actually active. Private-long-code voice privacy applies to the radio link, not to SIP/RTP or packet-data transport.

Authentication, OTASP A-key generation, and voice privacy have not been tested with femtocells.

Upgrading

To use these features, follow the upgrade guide to update an existing installation, then restart 1xBTS.