Authentication Call Flows

Authentication involves the use of the following components/procedures to determine a legitimate

mobile device.
Authentication Center (AC)
Authentication Center (AC) is the network element co-located with the CDMA SDHLR (Super Distributed
Home Location Register) which stores subscriber authentication information and specifically the Mobile
Station (MS) A-key value. AC allows the SDHLR to verify the identity of Mobile Stations (MS) for the
purpose of detecting and denying service to unauthorized mobiles.
AC controls authentication policies for the following:
Initiation of SSD update
Initiation/revocation of SSD sharing
Initiation of unique challenges
Calculation of unique challenge authentication signatures
Allow/Deny responses on authentication failures
Mobile Station (MS)
Mobile Station (MS) is the subscriber physical device. This device may be a handset, data card,
machine to machine equipment, or tracking/logistics equipment. In other words, any device that has
been provisioned to the SDHLR for use of CDMA voice and/or 1xRTT data. Each Mobile Station (MS)
contains the A-key value provisioned by the Mobile Station vendor.
Visitor Location Register (VLR)
Visitor Location Register (VLR) is a temporary profile of subscriber CDMA voice and 1xRTT information
that performs authentication signature calculation with the MS during authentication.
Super Distributed Home Location Register (SDHLR)
Super Distributed Home Location Register (SDHLR) serves as the Home Location Register (HLR) for the
CDMA network.
Mobile Switching Center (MSC)
Mobile Switching Center (MSC) provides primary routing between the CDMA wireless network routing
traffic to appropriate internal or external systems.
Base Station (BS)
The Base Station (BS) is a transmitting/receiving station for mobile station, paging services.
Cellular Authentication and Voice Encryption (CAVE)
Cellular Authentication and Voice Encryption (CAVE) is a set of algorithms used during the
authentication process. Based on the inputs used, the CAVE algorithm enables calculation of SSD
during the SSD Update procedure and authentication signatures during challenge/response procedures.
The CAVE algorithm used in CDMA is standardized and procedures are defined to ensure that both the
network and the MS are using the same version of CAVE algorithm during authentication
Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 1

Authentication Call Flows

Challenging Side

Challenged
Side
Challeng
e

Challenge,
Secret
Data
CAVE

Authentication
Response

Challenge,
Secret
Data
CAVE

Respons
e

Authentication
Response

Compare Responses,
Allow or Deny Service

The challenging side generates a challenge message and sends it to the challenged side. Using the
generated challenge message and stored shared secret data as input, the challenging side computes an
Authentication response using the CAVE algorithm. Using the challenge message received from the
challenging side and stored SSD as input, the challenged side computes an Authentication response
using CAVE. The challenged side sends its Authentication response to the challenging side. The
challenging side compares responses to verify whether the challenged side has the same shared secret
data. If responses are equal, then both sides have same shared secret data.

Authentication Key (A-Key)

The A-key (64-bit data) expressed in 20 decimal digits with an additional 6 digit checksum. The A-key
is the single most important and protected value in CAVE based authentication. The purpose of the Akey is to generate Shared Secret Data (SSD), specifically an SSD_A secondary key. The SSD is then used
during the authentication process to validate a mobile station (MS). This helps to protect the A-Key as
it is never communicated (over the air) between any network elements. The A-key is provisioned in
the Authentication Center (AC) during subscriber activation and devices swaps. The A-key is also
provisioned by the handset vendor into the mobile station (MS). Once provisioned, the A-key is never
shared outside the AC and MS, meaning the subscriber does not know the A-key value. A-key is not
deterministic and cannot be derived from any subscriber data such as MIN, ESN, device model, or
customer specific information. A-key is not viewable from the MS and requires administrative access to
the AC for viewable permissions.
Shared Secret Data (SSD)
Shared Secret Data (SSD) is a 128-bit value that is calculated using the CAVE algorithm with the A-key
as an input. This calculation occurs during a procedure called SSD Update. During the SSD Update
Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 2

Authentication Call Flows

procedure, both the Authentication Center (AC) and the Mobile Station (MS) separately calculate SSD.
Since this process relies on a MS having a legitimate A-key value provisioned, use of the SSD update
process is an easy way to turn off service to a cloned MS that is using an illegally obtained SSD value.
Keep in mind it is the SSD, not the A-key that is used during authentication. The 128-bit SSD consists of
two 64-bit keys: SSD_A and SSD_B. The SSD_A key is used during authentication to calculate
authentication signatures. When authentication documents refer to SSD during the authentication
process, they are generally referring to SSD_A.
Computation of SSD

Shared Secret Data Update (SSDUPD)

SSDUPD updates the Shared Secret Data at both the Authentication Center (AC) and Mobile Station (MS)
to insure that both have the same SSD. SSD Update can be initiated manually by a technician or
automatically upon call origination, call termination, or FLASH.
SSD (AC) = SSD (MS)

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 3

Authentication Call Flows

The AC begins the SSD update process by selecting a random number and using this number along with
ESN and A-key inputs into the CAVE algorithm to generate a new SSD value. The home system then
forwards this random number to the visited system using a RandomVariableSSD (RANDSSD) parameter.
Receipt of this RANDSSD parameter by the visited system initiates the SSD update process to the MS.
state. The SSD update process involves two authentication challenges. The first is a base station
challenge (BSCHALL) from the MS when the request to update SSD is received. The purpose of this
challenge is to allow the MS to verify that the SSD update request is being initiated from a legitimate
source. The second is a unique challenge after the MS has updated its SSD. The purpose of this
challenge is to validate that the new SSD value generated by the MS is legitimate. Once both
challenges are complete, the home system receives a status message indicating whether the process
was successful.
Global Challenge
Global Challenge is invoked whenever a Mobile Station (MS) attempts to access the network. The MS
calculates AUTHR on a network access. If the mobile is roaming the VLR also calculates AUTH and
compares it with the value calculated by the mobile.
Global

Challenge is used for the following types:

Registration
Call Origination
Call Termination
Flash Request
SMS Page Response

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 4

Authentication Call Flows

Base Station Challenge (BSCHALL)

The Base Station Challenge operation is used to request a response to a Base Station Challenge Order
received from the MS.

Unique Challenge
Unique Challenge is invoked by the AC during a successful Share Secret Data Update (SSDUPD), Global
Challenge failure, or manually on the AC by a technician. The VLR generates a random number,
RANDU, and send an unique challenge order to the MS. The MS uses RANDU to calculate its unique
challenge response, AUTHU and returns in the unique challenge order confirmation. The VLR compares
its own value of AUTHU with the value calculated by the MS to determine

Random Variable (RAND)

Random Variable (RAND) is a 32-bit global authentication value used as input to the CAVE algorithm for
MS authentication.
RANDC
The RANDC consists of the 8 most significant bits of the RAND and is used by the base station to prevalidate the system access message sent by the MS. The base station compares the RANDC received
from the MS to the 8 most significant bits of the active RAND being broadcast. While a system may
discard a system access message if a mismatch is detected, the mismatch does not necessarily indicate
that the MS attempting to access the system is fraudulent, only that a cloned MS scenario may exist.
For example, a mismatch could occur when an MS in a border area uses a RAND value being transmitted
by a neighboring system or when an MS fails to receive the RAND value being transmitted and uses a
default value (i.e. RAND = 0).

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 5

Authentication Call Flows

1.1.1

Call/Message Flows

Authentication Message Flows

Message Flow of SSD Update

1. To initiate SSDUPD, the AC assigns a RANDSSD and uses it along with the A-Key, ESN, and AAV to
compute a new SSD value.
The AC then sends SSD Update Order message with the RANDSSD value to the mobile.
2. Once the mobile receives SSD Update Update message, it uses the RANDSSD value received,
the A-Key (stored in the mobile), ESN, and AAV as inputs to the CAVE algorithm to calculate a
new SSD_New value.
3. To verify that the SSD Update Order message is from an authorized base station, the mobile
generates RANDBS and uses the newly calculated SSD_New value, ESN, and AAV to calculate an
AUTHBS value.
The mobile then sends the RANDBS value back to the AC in the Base Station Challenge
message.
4. When the AC receives the RANDBS, it uses the received RANDBS and the SSD_New value to
calculate an AUTHBS value.
It returns the AUTHBS value to the mobile in the Base Station Challenge Response message.
5. When the mobile receives the AUTHBS from the AC, it compares the AUTHBS received with the
AUTHBS it had calculated earlier.
If those values match, the mobile updates its SSD and sends back a positive
acknowledgment to the AC in the SSD Update Confirmation message.
Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 6

Authentication Call Flows

If the AUTHBS values do not match, the mobile sends back a negative acknowledgment
to the AC and maintains the old SSD.
6. When AC receives a positive acknowledgement message, it will update its SSD, otherwise it
maintains the old SSD.
Shared SSD
The AC communicates a MSs SSD to Visitor Location Registers (VLRs) which are capable of
executing the CAVE algorithm.
VLR also has a copy of SSD

The AC determines that the Shared Secret Data (SSD) in the MS must be updated. *******This may be
the result of administrative procedures at the AC, expiration of an authentication time interval at the
AC, or the report of a security violation from the visited system.*******
CAVE is executed at the AC to produce a pending value of the SSD using the A-key and ESN of the MS
along with the Random Number (RANDSSD) generated by the AC. Note that the AC must retain both the
current and pending values of the SSD until informed by the VLR of the outcome of the updating
procedure.
The AC/SDHLR sends an AUTHDIR to the current serving VLR.
The pending SSD shall be used to calculate RANDU, AUTHU and AUTHBS for the SSD Update operation.
The VLR chooses a Unique Random Variable (RANDU) and executes CAVE using the pending value of SSDA, ESN and MIN associated with the MS to produce a Unique Authentication Response (AUTHU).
The VLR forwards the AUTHDIR to the MSC including RANDU and the expected AUTHU result.
Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 7

Authentication Call Flows

An empty AUTHDIR is sent from the MSC to the VLR. This serves only to inform the VLR that the MSC
has accepted the directive.
The VLR forwards the AUTHDIR to the SDHLR/AC.
The MSC sends an SSD Update order to the MS using the value of RANDSSD provided by the AC.
The MS executes CAVE to produce a pending value of SSD using the value of RANDSSD provided in the
SSD Update order, ESN and A-key.
The MS selects a Random Number (RANDBS) and sends a Base Station Challenge order to the MSC
including the value of RANDBS.
The MS then executes CAVE to produce an Authentication Result (AUTHBS) using the pending value of
SSD-A, ESN, MIN and the Random Number (RANDBS)
The RANDBS is passed to the VLR by the MSC in a BSCHALL.
The VLR also executes CAVE to produce an Authentication Result (AUTHBS) using the pending value of
SSD-A, ESN, MIN for the MS and the Random Number (RANDBS) provided by the MS.
The VLR then provides its computed value of AUTHBS to the MSC in the BSCHALL.
The MSC passes this information through to the MS in a Base Station Challenge response message.
If the AUTHBS result provided by the VLR matches the value computed by the MA, the MS stores the
pending SSD value for use in the subsequent execution of CAVE and sends an SSD Update Confirmation
message to the MSC.
The MSC sends a Unique Challenge order to the MS using the RANDU provided in the AUTHDIR.
The MS executes CAVE using RANDU and the SSD-A currently stored, ESN, and MIN to produce an
Authentication Response for Unique Challenge (AUTHU) which is then sent to the MSC.
The MSC sends an ASREPORT to the VLR indicating that SSD updating has been successfully completed.
The VLR forwards the ASREPORT to the SDHLR/AC and removes the pending SSD.
The AC stores the pending SSD value for use in subsequent execution of CAVE for the MS if the SSD
Update was successful. The AC sends an ASREPORT to the VLR forwarded to the MSC indicating the
service is to be provided to the MS. The AC includes the new current SSD in the ASREPORT to share the
new current SSD value with the VLR.

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 8

Authentication Call Flows

Message Flow of Global Challenge during Registration

MS determines from the Overhead Message Train (OMT) that a new serving system has been entered and
that authentication is required on all system accesses (Auth=1). The Random Number (RAND) to be
used for authentication may also be obtained by the MS at this time.
The MS executes CAVE using the SSD-A currently stored, ESN, MIN and the RAND value to produce a
registration Authentication Result (AUTHR)
The MS registers at the serving MSC, providing its MIN, ESN, AUTHR and RANDC derived from the RAND
used to compute AUTHR.
MSC verifies RANDC supplied by the MS and sends the appropriate value of RAND and the AUTHR in an
AUTHREQ.
AUTHREQ forwarded from the MSC/VLR to the SDHLR/AC. AC verifies AUTHR and response Allow/Deny
in the AUTHREQ RR.
If allowed, a REGNOT is sent from the MSC to the VLR/SDHLR.

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 9

Authentication Call Flows

Message Flow of Global Challenge during Call Origination

MS determines from the Overhead Message Train (OMT) that a new serving system has been entered and
that authentication is required on all system accesses (Auth=1). The Random Number (RAND) to be
used for authentication may also be obtained by the MS at this time.
The MS executes CAVE using the dialed digits, ESN, and the SSD currently stored for produce an
origination Authentication Result (AUTHR)
The MS sends an origination message to the MSC providing the dialed digits, its MIN, ESN, AUTHR and
the RANDC from the RAND used to compute AUTHR.
MSC verifies RANDC supplied by the MS and sends the dialed digits along with appropriate value of
RAND and the AUTHR in an AUTHREQ.
AUTHREQ forwarded from the MSC/VLR to the SDHLR/AC. AC verifies AUTHR and response Allow/Deny
in the AUTHREQ RR.

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 10

Authentication Call Flows

Message Flow of Global Challenge during Call Termination

MS determines from the Overhead Message Train (OMT) that a new serving system has been entered and
that authentication is required on all system accesses (Auth=1). The Random Number (RAND) to be
used for authentication may also be obtained by the MS at this time.
The MS recognizes a page message with its MIN and executes CAVE using the SSD-A currently stored,
ESN, MIN and RAND value to produce a termination Authentication Result (AUTHR).
The MS sends a page response message to the MSC providing its MIN, ESN, AUTHR, and RANDC from the
RAND used to compute AUTHR.
MSC verifies RANDC supplied by the MS and sends the appropriate value of RAND and the AUTHR in an
AUTHREQ.
AUTHREQ forwarded from the MSC/VLR to the SDHLR/AC. AC verifies AUTHR and response Allow/Deny
in the AUTHREQ RR.

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 11

Authentication Call Flows

Message Flow of Global Challenge during Flash request

A call is established on the voice/digital traffic channel.

The MS sends a flash request (with digits) to the MSC, requesting a second (three party) call to be
established.
The MSC sends an AUTHREQ to the VLR with the SystemAccessType set to FlashRequest.
The VLR generates the RANDU, then AUTHU by executing CAVE, then sends an AUTHREQ to the MSC
containing the values of AUTHU and RANDU.
MSC sends a Unique Challenge to the MSC using the RANDU provided in the AUTHREQ.
The MS executes CAVE using RANDU and the SSD-A currently stored ESN, and MIN to produce an
Authentication Result (AUTHU) which is then sent to the MSC.
The MSC compares the value of AUTHU provided in the AUTHREQ with the that received from the MS.
MSC sends an ASREPORT to the VLR indicating allow/deny of the unique challenge that is passed back to
the MSC.

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 12

Authentication Call Flows

The authentication global challenge, unique challenge and base station challenge processes all use the
challenge - response mechanism to verify that the Authentication Center and the Mobile Station have
the same Shared Secret Data
Message Flow of Unique Challenge

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 13

Authentication Call Flows

Computation of SSD

Computation of AUTHR

Computation of AUTHU

Computation of AUTHBS

Design Document Template v3.3, 09/05/07

RESTRICTED

272860012.doc
Page 14