CDMA Authentication
CDG Document 138
Version 0.34
Oct. 12, 2006
CDMA Development Group
575 Anton Boulevard, Suite 560
Costa Mesa, California 92626
PHONE +1 888 800-CDMA
+1 714 545-5211
FAX +1 714 545-4601
http://www.cdg.org
cdg@cdg.org
Notice
Each CDG member acknowledges that CDG does not review the
disclosures or contributions of any CDG member nor does CDG
verify the status of the ownership of any of the intellectual property
rights associated with any such disclosures or contributions.
Accordingly, each CDG member should consider all disclosures
and contributions as being made solely on an as-is basis. If any
CDG member makes any use of any disclosure or contribution,
then such use is at such CDG member's sole risk. Each CDG
member agrees that CDG shall not be liable to any person or
entity (including any CDG member) arising out of any use of any
disclosure or contribution, including any liability arising out of
infringement of intellectual property rights.
CDMA Authentication
Contents
Contents
1. Introduction ................................................................................................................................ 1
2. Authentication Overview ........................................................................................................... 3
2.1 What is cloning fraud .......................................................................................................... 3
2.2 Why is authentication important ......................................................................................... 3
2.3 How effective is authentication ........................................................................................... 4
2.3.1 Regular clones ..................................................................................................... 4
2.3.2 Complete clones .................................................................................................. 4
2.3.3 Replay attacks ..................................................................................................... 5
2.4 Authentication concepts ..................................................................................................... 5
2.4.1 Cellular Authentication and Voice Encryption (CAVE) ........................................ 5
2.4.2 Authentication Key (A-key) .................................................................................. 5
2.4.3 Shared Secret Data (SSD) .................................................................................. 6
2.4.4 Challenge/Response mechanism ........................................................................ 7
2.5 Elements involved in authentication ................................................................................... 8
2.5.1 A-key Management System (AKMS) ................................................................... 8
2.5.2 Authentication Center (AC) ................................................................................. 8
2.5.3 Visitor Location Register (VLR) ........................................................................... 9
2.5.4 Mobile Station (MS) ............................................................................................. 9
3. Managing and Provisioning A-keys ....................................................................................... 11
3.1 A-key generation .............................................................................................................. 11
3.1.1 A-key generated by manufacturer ..................................................................... 11
3.1.2 A-key generated by carrier ................................................................................ 12
3.2 A-key provisioning ............................................................................................................ 12
3.2.1 Provisioning the AC ........................................................................................... 12
3.2.2 Provisioning the MS........................................................................................... 13
4. Home versus local authentication .......................................................................................... 15
4.1 Authentication by home system ....................................................................................... 15
4.2 Local authentication by visited system ............................................................................. 16
4.3 SystemCapabilities (SYSCAP) of visited system ............................................................. 16
4.4 Enabling and disabling local authentication ..................................................................... 17
5. Global Challenges .................................................................................................................... 19
5.1 Authentication signature (AUTHR) ................................................................................... 19
5.2 Roamer authenticated by its home system ...................................................................... 20
CDG #138, Rev 0.34
February 12, 2016
i
CDMA Authentication
Contents
5.3 Roamer authenticated locally by the visited system ........................................................ 21
5.4 Pre-validation using RANDC ............................................................................................ 21
5.5 Clone detection using COUNT ......................................................................................... 22
5.5.1 Updating CallHistoryCount (COUNT) ................................................................ 22
5.6 Reporting of results to roamer’s home system ................................................................ 23
6. Unique Challenges ................................................................................................................... 25
6.1 Authentication signature (AUTHU) ................................................................................... 25
6.2 Unique challenge initiated by roamer’s home system...................................................... 26
6.3 Unique challenge initiated locally by visited system ........................................................ 27
6.4 Reporting results to roamer’s home system .................................................................... 27
7. Updating Shared Secret Data (SSD)....................................................................................... 29
7.1 SSD update process when SSD is shared ...................................................................... 30
7.2 SSD update process when SSD is not shared ................................................................ 30
8. Authentication Enhancements ............................................................................................... 33
8.1 Roamers from a non-authentication-capable partner ...................................................... 33
8.2 Handling of suspicious call origination attempts .............................................................. 33
9. Over-The-Air (OTA) Support ................................................................................................... 35
9.1 OTASP ............................................................................................................................. 35
9.2 OTAPA ............................................................................................................................. 35
9.3 OTASP/OTAPA mechanism ............................................................................................ 35
9.3.1 OTASP attachment............................................................................................ 35
9.3.2 Action codes ...................................................................................................... 36
9.4 A-key generation procedure ............................................................................................. 37
9.5 SSD update ...................................................................................................................... 39
10. Recommendations ................................................................................................................. 41
10.1 A-key management recommendations .......................................................................... 41
10.1.1 Protect A-key information between manufacturer and AKMS ......................... 41
10.1.2 Protect A-key information between AKMS and AC ......................................... 41
10.1.3 Protect A-key information between AKMS and MS ......................................... 41
10.1.4 Delete A-keys from the AKMS once provisioned into MS and AC .................. 41
10.2 General authentication recommendations ..................................................................... 41
10.2.1 Use global challenges ..................................................................................... 41
10.2.2 Use the COUNT mismatch mechanism .......................................................... 42
10.2.3 Enable local authentication ............................................................................. 42
10.2.4 Perform an SSD update when activating a new MS ....................................... 42
10.2.5 Trigger fraud procedures on large or repeated COUNT mismatches ............. 42
CDG #138, Rev 0.34
February 12, 2016
ii
CDMA Authentication
Contents
10.2.6 Trigger a unique challenge when a cloned MS is suspected .......................... 42
10.2.7 Trigger an SSD update if cloning still suspected after unique challenge ........ 42
10.2.8 Ensure that roaming partner denies service if authentication fails .................. 42
10.3 Specific recommendations for identified scenarios ........................................................ 43
10.3.1 Cloned MS – valid ESN and MIN .................................................................... 43
10.3.2 Cloned MS – valid ESN, MIN, and SSD .......................................................... 43
10.3.3 Cloned MS – valid ESN, MIN, SSD, and A-key .............................................. 43
10.3.4 Replay attack with extra digits ......................................................................... 44
11. AKA-based Authentication ................................................................................................... 45
11.1 Authentication vectors (AVs) .......................................................................................... 45
11.2 AKA authentication process ........................................................................................... 46
11.3 Distribution of authentication vectors ............................................................................. 48
11.4 Authentication of the network by the MS ....................................................................... 49
11.4.1 Sequence number (SQN) ................................................................................ 50
11.4.2 Synchronization failure (i.e. SQN mismatch) .................................................. 50
11.4.3 Message authentication code (MAC_A) .......................................................... 51
11.4.4 AKA rejection by the MS (i.e. MAC_A mismatch) ........................................... 52
11.5 Authentication of the MS by the network ....................................................................... 53
11.5.1 Authentication response (RES) ....................................................................... 53
11.5.2 AKA authentication failure (i.e. RES mismatch) .............................................. 53
12. References .............................................................................................................................. 55
13. Terminology............................................................................................................................ 57
14. TIA-41-D Authentication Reference ...................................................................................... 61
14.1 TIA-41-D new relevant operations ................................................................................. 61
14.1.1 AuthenticationDirective (AUTHDIR) ................................................................ 61
14.1.2 AuthenticationDirectiveForward (AUTHDIRFWD) ........................................... 61
14.1.3 AuthenticationFailureReport (AFREPORT) ..................................................... 61
14.1.4 AuthenticationRequest (AUTHREQ) ............................................................... 62
14.1.5 AuthenticationStatusReport (ASREPORT) ..................................................... 62
14.1.6 BaseStationChallenge (BSCHALL) ................................................................. 62
14.1.7 CountRequest (COUNTREQ) ......................................................................... 62
14.1.8 RandomVariableRequest (RANDREQ) ........................................................... 63
14.2 TIA-41-D new relevant parameters ................................................................................ 63
14.2.1 AuthenticationAlgorithmVersion (AAV)............................................................ 63
14.2.2 AuthenticationCapability (AUTHCAP) ............................................................. 63
14.2.3 AuthenticationData (AUTHDATA) ................................................................... 63
CDG #138, Rev 0.34
February 12, 2016
iii
CDMA Authentication
Contents
14.2.4 AuthenticationResponse (AUTHR) .................................................................. 63
14.2.5 AuthenticationResponseBaseStation (AUTHBS) ............................................ 63
14.2.6 AuthenticationResponseUniqueChallenge (AUTHU) ...................................... 63
14.2.7 CallHistoryCount (COUNT) ............................................................................. 64
14.2.8 CallHistoryCountExpected (COUNTEx) .......................................................... 64
14.2.9 CountUpdateReport (COUNTRPT) ................................................................. 64
14.2.10 DenyAccess (DENACC) ................................................................................ 64
14.2.11 RANDC .......................................................................................................... 64
14.2.12 RandomVariable (RAND) .............................................................................. 64
14.2.13 RandomVariableBaseStation (RANDBS) ...................................................... 65
14.2.14 RandomVariableSSD (RANDSSD) ............................................................... 65
14.2.15 RandomVariableUniqueChallenge (RANDU) ................................................ 65
14.2.16 RANDValidTime (RANDVT) .......................................................................... 65
14.2.17 ReportType (RPTTYP) .................................................................................. 65
14.2.18 SharedSecretData (SSD) .............................................................................. 65
14.2.19 SSDNotShared (NOSSD) .............................................................................. 66
14.2.20 SSDUpdateReport (SSDURPT) .................................................................... 66
14.2.21 SystemCapabilities (SYSCAP) ...................................................................... 66
14.2.22 UniqueChallengeReport (UCHALRPT) ......................................................... 66
14.2.23 UpdateCount (UPDCOUNT) ......................................................................... 66
15. TIA-41-E Authentication Reference ...................................................................................... 67
15.1 TIA-41-E updates to existing relevant operations .......................................................... 67
15.1.1 AuthenticationDirective (AUTHDIR) ................................................................ 67
15.1.2 AuthenticationDirectiveForward (AUTHDIRFWD) ........................................... 67
15.1.3 AuthenticationFailureReport (AFREPORT) ..................................................... 68
15.1.4 AuthenticationRequest (AUTHREQ) ............................................................... 68
15.1.5 AuthenticationStatusReport (ASREPORT) ..................................................... 68
15.1.6 BaseStationChallenge (BSCHALL) ................................................................. 68
15.1.7 CountRequest (COUNTREQ) ......................................................................... 69
15.1.8 RandomVariableRequest (RANDREQ) ........................................................... 69
15.1.9 SMSDeliveryPointToPoint (SMDPP) ............................................................... 69
15.2 TIA-41-E new relevant operations.................................................................................. 69
15.2.1 OTASPRequest (OTASPREQ) ....................................................................... 69
15.3 TIA-41-E updates to existing relevant parameters......................................................... 70
15.3.1 ActionCode (ACTCODE) ................................................................................. 70
15.3.2 SystemCapabilities (SYSCAP) ........................................................................ 70
CDG #138, Rev 0.34
February 12, 2016
iv
CDMA Authentication
Contents
15.4 TIA-41-E new relevant parameters ................................................................................ 71
15.4.1 AKeyProtocolVersion (AKEYPV) ..................................................................... 71
15.4.2 AuthenticationResponseReauthentication (AUTHRA) .................................... 71
15.4.3 BaseStationPartialKey (BSKEY) ..................................................................... 71
15.4.4 MobileStationPartialKey (MSKEY) .................................................................. 71
15.4.5 OTASP_ResultCode (OTASPRC) ................................................................... 71
15.4.6 RandomVariableReauthentication (RANDRA) ................................................ 71
15.4.7 ReauthenticationReport (RARPT) ................................................................... 71
15.4.8 SuspiciousAccess (SUSACC) ......................................................................... 72
16. TIA-945 Authentication Reference ....................................................................................... 73
16.1 TIA-945 updates to existing authentication operations .................................................. 73
16.1.1 AuthenticationRequest (AUTHREQ) ............................................................... 73
16.1.2 RegistrationNotification (REGNOT) ................................................................. 73
16.2 TIA-945 new authentication operations ......................................................................... 73
16.2.1 AKADirective (AKADIR)................................................................................... 73
16.2.2 AKARequest (AKAREQ) ................................................................................. 73
16.2.3 AKAStatusReport (AKAREPORT)................................................................... 74
16.3 TIA-945 updates to existing authentication parameters................................................. 74
16.3.1 AuthenticationCapability (AUTHCAP) ............................................................. 74
16.3.2 SystemCapabilities (SYSCAP) ........................................................................ 74
16.4 IS-945 new authentication parameters .......................................................................... 74
16.4.1 AKA_AuthenticationVector (AKAV) ................................................................. 74
16.4.2 AKA_AuthenticationVectorList (AKAVL) ......................................................... 75
16.4.3 AKA_Keys (AKAK) .......................................................................................... 75
16.4.4 AKA_Report ..................................................................................................... 75
16.4.5 AKA_VectorCount ........................................................................................... 75
16.4.6 AUTS ............................................................................................................... 75
16.4.7 RANDA ............................................................................................................ 75
CDG #138, Rev 0.34
February 12, 2016
v
CDMA Authentication
Figures
Figures
Figure 2-1: Susceptibility of MS identity information .................................................................... 3
Figure 2-2: Shared Secret Data (SSD) ......................................................................................... 7
Figure 2-3: Challenge/Response Mechanism .............................................................................. 8
Figure 3-1: Retrieval of pre-programmed A-keys from manufacturers ....................................... 11
Figure 3-2: Provisioning the AC .................................................................................................. 12
Figure 3-3: A-key programmed by manufacturer ....................................................................... 13
Figure 3-4: A-key programmed using secure device at retailer ................................................. 13
Figure 3-5: A-key obtained by contacting customer care ........................................................... 14
Figure 4-1: Home versus local authentication ............................................................................ 15
Figure 4-2: Authentication by home system ............................................................................... 15
Figure 4-3: Local authentication ................................................................................................. 16
Figure 5-1: Global challenge to MS ............................................................................................ 19
Figure 5-2: Generation of AUTHR for global challenge .............................................................. 20
Figure 5-3: Global challenge message flow when SSD is not shared ....................................... 20
Figure 5-4: Global challenge message flow when SSD is shared ............................................. 21
Figure 5-5: COUNT update process ........................................................................................... 22
Figure 5-6: Authentication reporting for unique challenges ........................................................ 23
Figure 6-1: Unique challenge to MS ........................................................................................... 25
Figure 6-2: Generation of AUTHU for unique challenge ............................................................ 25
Figure 6-3: Unique challenge initiated by roamer’s home system.............................................. 26
Figure 6-4: Unique challenge initiated by visited system ........................................................... 27
Figure 6-5: Authentication reporting for unique challenges ........................................................ 28
Figure 7-1: SSD update process when SSD is shared .............................................................. 30
Figure 7-2: SSD update process when SSD is not shared ........................................................ 31
Figure 8-1: Handling of suspicious access attempts .................................................................. 34
Figure 9-1: OTASP attachment between MSC and OTAF ......................................................... 36
Figure 9-2: OTASP A-key generation procedure ....................................................................... 38
Figure 9-3: A-key generation call flow ........................................................................................ 39
Figure 9-4: OTAF-initiated SSD update procedure .................................................................... 40
Figure 11-1: Information contained in an authentication vector ................................................. 46
Figure 11-2: Simplified conceptual flow of AKA authentication .................................................. 47
Figure 11-3: Distribution of AVs to the visited system ................................................................ 49
Figure 11-4: Generation of AK for AKA ...................................................................................... 50
Figure 11-5: AKA synchronization failure (i.e. SQN mismatch).................................................. 51
Figure 11-6: Generation of (X)MAC_A for AKA .......................................................................... 52
Figure 11-7: AKA rejection by the MS (i.e. MAC_A mismatch) .................................................. 52
Figure 11-8: Generation of (X)RES for AKA ............................................................................... 53
Figure 11-9: AKA response failure (i.e. RES mismatch) ............................................................ 54
CDG #138, Rev 0.34
February 12, 2016
vi
CDMA Authentication
Tables
Tables
1-1: Evolution of CDMA authentication......................................................................................... 2
4-1: Messages that may be used to enable or disable local authentication ............................... 17
5-1: Authentication parameters provided by MS when global challenges are required ............. 19
5-2: Messages that may contain UpdateCount to initiate COUNT update process ................... 23
7-1: Messages that may contain RANDSSD to initiate SSD update process ............................ 29
8-1: Authentication enhancements in IS-778 ............................................................................. 33
9-1: New action codes defined in TIA-41-E ................................................................................ 37
CDG #138, Rev 0.34
February 12, 2016
vii
CDMA Authentication
Introduction
1. Introduction
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
This paper specifically focuses on the security concept of authentication. While written from
the perspective of roaming, the authentication information presented herein should be useful
for any carrier interested in implementing or updating authentication support.
Both 2nd generation authentication based on Cellular Authentication and Voice Encryption
(CAVE) and 3rd generation authentication based on Authentication and Key Agreement
(AKA) are addressed in this paper. In the context of CAVE, the term authentication refers to
primarily unilateral1 mechanisms that allow the network to validate the authenticity of the
roaming mobile station (MS). In the context of AKA, these mechanisms are bilateral and
support both network validation of MS authenticity and MS validation of network authenticity.
Additional security concepts such as encryption, data integrity, and security associations
may be mentioned but are considered to be outside the scope of this paper.
While this paper addresses both CAVE- and AKA-based authentication, the larger focus is
on CAVE. The reasoning for this choice of focus is to provide carriers with information,
insight, and recommendations on the authentication mechanisms currently being deployed.
CAVE continues to be deployed and will likely continue to be the most prevalent form of
authentication for the next several years while the industry migrates to AKA. During this
migration, interoperability will necessitate that AKA deployment be done in conjunction with
support for CAVE rather than as a complete replacement.
The discussion of CAVE-based authentication begins with an overview of authentication
issues and concepts, an introduction to A-key considerations, and an explanation of the
mechanisms employed by CAVE as defined in TIA-41-D. Following this, TIA-41-E
authentication enhancements and Over-The-Air (OTA) support are discussed. Finally,
practical recommendations are provided.
Information on CAVE is followed by an exploration of AKA-based authentication. AKA
concepts and details are presented in sufficient detail to allow carriers unfamiliar with AKA to
thoroughly understand AKA authentication mechanisms.
As may or may not be apparent, this progression of information maps roughly to the
evolution of CDMA authentication beginning with the introduction of network support for
CAVE-based authentication in TSB51 to the introduction of network support for AKA in TIA945. This standards evolution is shown in the following table.
1 While the process of updating Shared Secret Data (SSD) in CAVE-based authentication does allow
the MS to validate the authenticity of the network using a base station challenge, once SSD has been
updated, CAVE-based authentication is unilateral (i.e. the network always authenticates the MS).
CDG #138, Rev 0.34
February 12, 2016
1
CDMA Authentication
Introduction
1-1: Evolution of CDMA authentication
1
Release
Dec. 1991
Document
IS-41-B
Description
Intersystem operations (no authentication support)
May 1993
TSB51
CAVE-based authentication
Feb. 1996
IS-41-C
Jun. 1997
IS-725
Dec. 1997
Jan. 1999
TIA-41-D
IS-778
Intersystem operations with TSB51-based
authentication incorporated
OTASP capabilities including support for over-the-air
A-key provisioning
Essentially the same as IS-41-C
Enhancements to TIA-41-D authentication
Jan. 1999
2004 – 2005
IS-725-A
TIA-41-E
Oct. 2005
TIA-945
Adds OTAPA capabilities as well as OTASP
Intersystem operations with IS-725-A and IS-778
incorporated
MAP support of Authentication and Key Agreement
(AKA) alternative to CAVE-based authentication
2
3
4
5
6
7
8
9
10
11
Reference sections containing various authentication operations, parameters, and fields
discussed throughout the paper are provided at the end of the paper. These sections are
separated into TIA-41-D, TIA-41-E, and TIA-945. References and modifications to existing
items are highlighted to allow the reader to understand when various items were introduced
and modified. These sections are not intended as a proxy to the standards documents for
the purposes of implementation. Rather, the inclusion of these sections is an attempt to
reduce reader frustration as often times being able to quickly reference additional
information such as which field values are supported by a particular parameter can clarify
uncertainty regarding its use or purpose.
12
CDG #138, Rev 0.34
February 12, 2016
2
CDMA Authentication
Authentication Overview
2. Authentication Overview
1
2
3
4
5
6
7
8
9
2.1 What is cloning fraud
A cloned mobile station or “clone” is simply a Mobile Station (MS) that has been
programmed with illegally obtained Equipment Serial Number (ESN) and Mobile Station
Identity (MSID) information. Because these ESN and MSID values are sent unencrypted
over the air interface by the MS to identify itself to the network, it is possible for a fraudster to
intercept them. However, it may also be possible for fraudsters to obtain these values from
the MS if they are able to access programming mode or work with employees of a carrier to
steal them.
ESN, MSID
MS identifies itself to
the network by sending
its ESN and MSID
values unencrypted
over the air interface.
10
11
Figure 2-1: Susceptibility of MS identity information
12
In any event, once these values have been obtained by a fraudster, they can be
programmed into other mobile stations to create clones. The use of clones to fraudulently
access a carrier network is known as cloning fraud and is the most prevalent form of
technical fraud in CDMA networks.
13
14
15
21
While this may seem very complex for the average criminal to attempt, tools to assist in the
creation of clones are only an Internet search away. For example, for a few hundreds
dollars, a fraudster can readily purchase software and universal handset programming
equipment that allows them to reprogram a mobile station with new values for ESN, MSID,
A-key, etc… In the past, such equipment was only available to carriers for troubleshooting
purposes and cost thousands of dollars.
22
2.2 Why is authentication important
16
17
18
19
20
23
24
25
26
27
28
29
30
31
Cloning fraud has several costs. First, carriers incur lost revenue potential in the form of not
being compensated for fraudulent use. Next, customer care resources must be expended to
work with legitimate subscribers that have been cloned in order to resolve billing issues and
reprogram mobile stations. Finally, potential switching and intangible costs are associated
with lower customer satisfaction when these legitimate subscribers discover fraudulent
charges on their bills. In short, the result of cloning fraud is that carrier’s lose money and
legitimate subscribers are unhappy.
When a mobile station is cloned and used to fraudulently access the network of a roaming
partner, this situation is exacerbated. In the roaming scenario, not only does the home
CDG #138, Rev 0.34
February 12, 2016
3
CDMA Authentication
1
2
3
Authentication Overview
network incur the aforementioned costs, but it must also pay the roaming partner for the
intercarrier roaming charges resulting from the fraudulent access. This translates into real
monetary costs that directly affect the home network’s bottom line.
7
Authentication protects carrier networks from fraudulent access by cloned mobile stations.
The mechanisms used by CAVE-based authentication ensure that a mobile station possess
valid shared secret data before allowing it to access the network. These mechanisms
protect both carriers and legitimate subscribers from the negative effects of cloning fraud.
8
2.3 How effective is authentication
4
5
6
9
10
11
12
13
The following subsections discuss the effectiveness of authentication in various technical
fraud scenarios. However, it should be noted that how effective an authentication
implementation is depends largely on policy decisions made by the home and visited
network. These policy decisions can make the difference between an effective and a
frustratingly ineffective implementation. For example:
14

Is A-key information sufficiently protected?
15

Is authentication used in both roaming and non-roaming scenarios?
16

Are unique challenges used?
17

Is the Call History Count (COUNT) mechanism effectively used?
18

Are global challenge values frequently changed?
19
2.3.1 Regular clones
20
25
CAVE-based authentication is completely effective against regular cloning fraud. Any
attempt by a regular clone to access a network using authentication should be unsuccessful.
The reason is that, while the regular clone can identify itself as another subscriber using
illegally obtained ESN and MSID information, it will not possess valid shared secret data
required to successfully pass an authentication challenge. Therefore, authentication will
completely solve the majority of cloning fraud.
26
2.3.2 Complete clones
21
22
23
24
27
28
29
30
31
32
33
34
35
36
A less likely but more problematic scenario is the existence of a “complete clone.” A
complete clone is one that contains a correct A-key. Complete clones are more problematic
because they are able to successful complete SSD update procedures and authentication
challenges.
The existence of a complete clone indicates a problem with a carrier’s security procedures
that has allowed A-key information to be compromised. Nonetheless, as will be discussed
later in this paper, CAVE-based authentication provides a Call History Count (COUNT)
mechanism to help identify the existence of clones, even in the case of a complete clone.
Once identified, service may be denied, though this action will require the legitimate
subscriber to contact customer care to re-activate their service.
CDG #138, Rev 0.34
February 12, 2016
4
CDMA Authentication
Authentication Overview
1
2.3.3 Replay attacks
2
8
A replay attack is a special scenario in which a fraudster intercepts the entire contents of a
legitimate roamer’s message and “replays” this information from a clone. Because the
intercepted message contained a correct global challenge response required to successfully
complete authentication, the replayed message will also successfully complete
authentication if the challenge value is the same. Therefore, replay attacks are inherently
limited by how frequently the visited network changes the global challenge value sent to all
mobile stations attempting to access the network.
9
2.4 Authentication concepts
3
4
5
6
7
10
11
12
13
14
15
16
2.4.1 Cellular Authentication and Voice Encryption (CAVE)
Cellular Authentication and Voice Encryption (CAVE) is a set of cryptographic2 algorithms
collectively referred to as the CAVE algorithm which are 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 is also used to calculate various values used during
optional encryption and voice privacy procedures which are not discussed in this document.
22
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. If the MS is equipped with a removable user identity module (R-UIM), the
CAVE algorithm will reside on this R-UIM and all authentication calculations using the CAVE
algorithm will be performed by the R-UIM. Otherwise, the MS will perform these
calculations.
23
2.4.2 Authentication Key (A-key)
17
18
19
20
21
24
25
26
27
28
29
30
31
32
33
34
Also known as the “master key”, the A-key is the cornerstone of CAVE-based authentication.
The A-key is provisioned in the home Authentication Center (AC) and the mobile station
(MS). If the MS uses an R-UIM, the A-key is stored on this R-UIM; otherwise, the A-key is
stored in semi-permanent memory on the MS. In either case, users should not be able to
access or view the A-key on their MS. Once provisioned, an A-key is generally only
changed if the home operator suspects that it has been compromised.
The purpose of the A-key in authentication is to generate Shared Secret Data (SSD),
specifically an SSD_A secondary key. It is this SSD, not the A-key, that is used during the
authentication process. This helps protect the A-key from being compromised. While SSD
may be shared with a partner network to enable local authentication, the A-key, once
provisioned, is never shared outside of the MS and home AC.
2 Useless knowledge for your next dinner party: cryptography comes from the Greek words kryptos
and graphein, which together mean “hidden writing”.
CDG #138, Rev 0.34
February 12, 2016
5
CDMA Authentication
Authentication Overview
1
2.4.3 Shared Secret Data (SSD)
2
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 procedure, both the Authentication Center (AC) and the Mobile
Station (MS) separately calculate SSD. It is this SSD, not the A-key that is used during
authentication.
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Note that the term “Shared Secret Data” refers to the fact that the secret data is shared
between the network and the MS. This SSD may or may not also be shared between home
and roaming partner networks. If the home network chooses not to share SSD with their
roaming partner network, it is still shared between home network and MS. If the home
network does share SSD with their roaming partner network, it is referred to as “Shared
SSD” because the SSD shared between home network and MS is also shared with the
partner network.
As shown below, the 128-bit SSD actually consists of two 64-bit keys: SSD_A and SSD_B.
The SSD_A key is the one used during authentication to calculate authentication signatures.
When authentication documents refer to SSD during the authentication process, they are
generally referring to SSD_A. The SSD_B key is not detailed in this document as its
purpose is to enable the generation of session keys that are used during optional encryption
and voice privacy procedures.
CDG #138, Rev 0.34
February 12, 2016
6
CDMA Authentication
Authentication Overview
64-bit
A-Key
ESN
RAND_SSD
CAVE algorithm
64-bit
64-bit
SSD_A
SSD_B
SSD_A is used during
authentication to
generate response
signatures
SSD_B is used to
generate session
keys that enable
voice privacy and
encryption
1
SSD is a 128-bit value
that actually consists
of two 64-bit keys:
SSD_A and SSD_B
2
Figure 2-2: Shared Secret Data (SSD)
3
Use of the SSD rather than the A-key during authentication helps to protect the A-key from
being compromised since SSD may be shared with a roaming partner network but the A-key
is never shared. In addition, sharing SSD allows partner networks to locally perform
authentication rather than requiring all partner networks to proxy authentication signaling
back to the home HLR/AC. As a home network scales its roaming business with additional
partner networks, sharing of SSD becomes increasingly important for reducing signaling
costs and preventing the HLR/AC from becoming a bottleneck.
4
5
6
7
8
9
10
2.4.4 Challenge/Response mechanism
11
Authentication is based on a challenge/response mechanism. This mechanism involves the
serving network challenging the MS with a randomly generated value. The MS uses this
challenge value along with its SSD and other information such as its ESN as inputs into the
CAVE algorithm to generate an authentication signature.
12
13
14
15
16
17
18
As shown below, this authentication signature is sent by the MS as a response to the
network’s challenge. As this document focuses on authentication in the context of roaming,
the scenario shown below is that of a roamer being authenticated by a visited network .
However, the mechanism is conceptually the same for a non-roaming scenario.
CDG #138, Rev 0.34
February 12, 2016
7
CDMA Authentication
Authentication Overview
SSD
A-key
HLR/AC
SSD
Home Network
Challenge (Challenge Value)
SSD
Response (Auth Signature)
A-key
MSC/VLR
Visited Network
1
2
Figure 2-3: Challenge/Response Mechanism
3
If SSD has been shared with the serving network, the MSC/VLR performs the same
calculation. If the SSD has not been shared, the MSC/VLR proxies the authentication
signature from the MS to the home HLR/AC where this calculation will be performed. In
either case, the authentication signature calculated by the network (i.e. HLR/AC or
MSC/VLR) is compared to the one calculated by the MS to determine whether the MS is
authentic.
4
5
6
7
8
12
This mechanism works because, in order for the calculated values to match, the SSD input
that was used by the network during its calculation must be the same as the SSD input that
was used by the MS. Essentially, authentication provides the network with a way to ensure
that the MS possesses correct SSD.
13
2.5 Elements involved in authentication
14
2.5.1 A-key Management System (AKMS)
15
20
The A-key Management System (AKMS) refers to the system by which a carrier securely
manages A-key values. This typically involves secure retrieval, random generation, storage,
and distribution of A-key values. The purpose of the AKMS is to ensure that A-key values
remain secure while enabling them to be provisioned into both the HLR/AC and MS. Ideally,
the AKMS is a dedicated, secure element maintained by the carrier; however, in practice, it
may simply be a set of procedures for ensuring the security of A-key information.
21
2.5.2 Authentication Center (AC)
22
Often collocated with the Home Location Register (HLR) and referred to as the HLR/AC, the
Authentication Center (AC) is where A-key information for each subscriber is stored. When
a new subscriber is activated, the A-key value provisioned in the MS must also be
provisioned in the AC.
9
10
11
16
17
18
19
23
24
25
CDG #138, Rev 0.34
February 12, 2016
8
CDMA Authentication
1
Authentication Overview
The AC controls authentication processes and policies such as the following:
2

Initiation of SSD update procedures
3

Initiation/revocation of SSD sharing
4

Calculation of global challenge authentication signatures when SSD is not shared
5

Initiation of unique challenges
6

Calculation of unique challenge authentication signatures
7

Comparison of network and MS authentication signatures when SSD is not shared
8

Initiation of Call History Count updates
9

How to respond to authentication failures
10
2.5.3 Visitor Location Register (VLR)
11
Often collocated with the Mobile Switching Center (MSC) and referred to as the MSC/VLR,
the Visitor Location Register (VLR) interacts with the roaming MS during authentication. If
SSD is not shared, the MSC/VLR simply proxies authentication signaling between the
HLR/AC and the MS. However, the more common scenario is for SSD to be shared.
12
13
14
17
When SSD is shared, the MSC/VLR locally performs authentication signature calculation
and comparison. This approach both reduces signaling between home and visited networks
and offloads authentication processing that would otherwise be performed by the HLR/AC.
18
2.5.4 Mobile Station (MS)
19
The A-key value provisioned in an activated Mobile Station (MS) will match the A-key value
provisioned in the home HLR/AC associated with that subscriber. To participate in
authentication procedures, the MS must have the CAVE algorithm and be capable of using
this algorithm to generate new SSD during SSD update procedures and authentication
signatures during challenge/response procedures.
15
16
20
21
22
23
24
25
26
27
Basically, all new CDMA handsets are authentication capable. Many new handsets also
support removable user identity modules (R-UIM). If the MS uses an R-UIM, the CAVE
algorithm will reside on this R-UIM and all authentication calculations using CAVE will be
performed by the R-UIM. Otherwise, the MS will perform these calculations.
CDG #138, Rev 0.34
February 12, 2016
9
CDMA Authentication
1
Managing and Provisioning A-keys
3. Managing and Provisioning A-keys
5
The management and provisioning of A-key values is controlled by an element known as the
A-Key Management System (AKMS). This element provides for secure retrieval, random
generation, storage, and distribution of A-key values. The AKMS ensures that A-key values
remain secure and supports the provisioning of these values into both the MS and AC.
6
3.1 A-key generation
7
3.1.1 A-key generated by manufacturer
8
The most common method of programming A-keys into mobile stations is for the A-key value
to be generated by the manufacturer and pre-programmed into the MS at the factory. When
this method is used, the manufacturer must also provide the ESN/A-key information to the
carrier for storage in the AKMS as illustrated below. Before activating a pre-programmed
MS, the AKMS must provision the ESN and A-key associated with the MS into the AC.
2
3
4
9
10
11
12
Manufacturers
Carrier
ESN / A-key
information
AKMS
Secure EDI or
encrypted file
Manufacturer
AAA
Manufacturer
BBB
Manufacturer
CCC
13
14
Figure 3-1: Retrieval of pre-programmed A-keys from manufacturers
15
To ensure the secure transport of ESN/A-key data between manufacturer and carrier, two
approaches are commonly used. The first, and most robust, approach involves the use of
an Electronic Data Interchange (EDI) between the manufacturer’s database subsystem and
the carrier’s AKMS. This approach allows the AKMS to directly retrieve A-key information
from a manufacturer’s database subsystem with no risk of exposing the information to
anyone within the carrier organization. However, while this solution works very well, smaller
carriers often do not have access to an EDI infrastructure.
16
17
18
19
20
21
22
23
24
25
The second, and more widely used, approach involves the manufacturer providing the
carrier with an encrypted file containing the list of ESN/A-key pairs. The carrier then typically
uses a script to automatically decrypt and upload this information into the AKMS. This
method is somewhat less secure than the EDI infrastructure approach since a person with
CDG #138, Rev 0.34
February 12, 2016
11
CDMA Authentication
Managing and Provisioning A-keys
3
access to the script could potentially decrypt and access the contents of the file. However,
many carriers find this approach to be an equitable tradeoff between security and costeffectiveness.
4
3.1.2 A-key generated by carrier
1
2
5
6
7
8
The carrier’s AKMS typically provides for the secure generation of random A-key values. In
addition to supporting activation of mobile stations without pre-programmed A-key values,
this capability provides the flexibility to re-program legitimate mobile stations with new A-key
values in cases where fraud has been detected.
13
Practices such as using all zero default A-key values are not recommended since they allow
the A-key to be easily guessed by fraudsters, thereby compromising the effectiveness of
authentication. Whether provisioned by the manufacturer or AKMS, A-keys should always
be securely and randomly generated and protected from being viewed to the greatest extent
practicable.
14
3.2 A-key provisioning
15
3.2.1 Provisioning the AC
16
A-keys may either be generated by the MS manufacturer and provided to the carrier for
storage in the AKMS or generated by the AKMS itself. In either case, in order for service to
be activated, an A-key value must be provisioned into the AC as illustrated below.
9
10
11
12
17
18
Secure
provisioning or
OTASP A-key
generation
A-key
A-key
AKMS
AC
19
Figure 3-2: Provisioning the AC
20
21
22
23
24
25
26
27
28
29
Since both the AKMS and AC reside within the carrier’s network, the mechanism by which
the AKMS provides MIN/ESN/A-key information to the AC is an internal issue. However,
because the A-key is involved, the transfer of information between these entities should be
secure and protected from being viewed to the greatest extent practicable. Wherever
possible, it is recommended that automated methods of retrieving the A-key from the AKMS
and provisioning it into the AC during activation be used.
Some implementations involve A-key values being internally generated by the AC. In such
cases, the AKMS function is essentially incorporated into the AC and there is no transfer of
A-key information between AKMS and AC entities.
CDG #138, Rev 0.34
February 12, 2016
12
CDMA Authentication
Managing and Provisioning A-keys
1
3.2.2 Provisioning the MS
2
4
Provisioning of the MS may be implemented in several ways. The following subsections
discuss various methods that are available to carriers to facilitate the provisioning of A-key
values into mobile stations.
5
3.2.2.1 A-key programmed by manufacturer
6
As previously mentioned, pre-programming of A-keys into mobiles stations by the
manufacturer is the most common method currently in use. When this method is used, the
manufacturer will also provide the pre-programmed A-keys to the carrier’s AKMS where they
are stored until needed for service activation. This scenario is illustrated below.
3
7
8
9
A-key
Manufacturer
database
A-key
A-key
AKMS
AC
10
11
Figure 3-3: A-key programmed by manufacturer
12
15
Pre-programmed A-keys are not mutually exclusive with the use of other methods discussed
herein to program an A-key into an MS. In other words, the fact that an MS has been preprogrammed with an A-key value by the manufacturer does not prevent the carrier from
generating and programming a new A-key value into the MS if needed or preferred.
16
3.2.2.2 A-key programmed at the retailer
17
Another option for provisioning the MS is to allow it to occur at the point of sale, i.e. at the
retailer. The secure approach to enabling retailer provisioning of mobile stations is for the
retailer to utilize an MS programming device (e.g. Synacom Validator) that communicates
directly with the carrier’s AKMS to retrieve A-keys as illustrated below.
13
14
18
19
20
A-key
A-key
A-key
AKMS
AC
Secure MS
programming
device
21
22
Figure 3-4: A-key programmed using secure device at retailer
23
Encryption on the communications link between the programming device and the AKMS
allows the A-key to be securely retrieved from the AKMS and protected from view by the
24
CDG #138, Rev 0.34
February 12, 2016
13
CDMA Authentication
Managing and Provisioning A-keys
2
retailer. This approach also removes the potential for human error in entering the A-key by
allowing the programming device to retrieve the A-key and program it directly into the MS.
3
3.2.2.3 A-key programmed using OTASP A-key generation procedure
4
8
Perhaps the most flexible option for programming the A-key into the MS is the use of OverThe-Air Service Provisioning (OTASP). MAP support for OTASP was introduced in IS-725
with support for Over-The-Air Parameter Administration (OTAPA) added in IS-725-A.
OTASP/OTAPA support in IS-725-A was later incorporated into TIA-41-E. For more
information, see the 9. Over-The-Air (OTA) Support section of this paper.
9
3.2.2.4 A-key obtained by contacting customer care
1
5
6
7
10
11
12
13
14
15
This final approach involves a subscriber, retailer, or technician calling the carrier’s customer
care center from a working phone to obtain the A-key. Once the caller has been determined
to be legitimate, customer care requests a new A-key value from the AKMS. The AKMS
securely and randomly generates the new A-key value and provides this value to both
customer care and the AC. Customer care may then provide the A-key value to the caller for
manual entry into the MS. This approach is illustrated below.
A-key
AKMS
AC
A-key
A-key
A-key
Customer
Care
16
17
Figure 3-5: A-key obtained by contacting customer care
18
Because the previously discussed alternatives for programming the A-key into the MS
provide greater security and less user interaction, this approach is more often used for
troubleshooting than new service activation. However, if carriers do choose to use this
approach for new service activation, it is recommended that they also have fraud detection
systems in place to detect excessive SSD updates that would occur when legitimate A-keys
are being programmed into cloned mobile stations.
19
20
21
22
23
CDG #138, Rev 0.34
February 12, 2016
14
CDMA Authentication
Home versus local authentication
4. Home versus local authentication
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Authentication of a roaming MS may be
performed by the roamer’s home system
or locally by the system to which the MS
is attempting to gain access. However,
roaming partners most commonly
choose to support local authentication
because of its advantages in reducing
signaling between visited and home
systems. The two primary requirements
for supporting local authentication
include: (1) the ability of the visited VLR
to support CAVE algorithms for local
calculation of authentication signatures
and (2) the willingness of the home
system to share SSD with the visited
VLR to enable these calculations.
Auth required
NO
Visited
supports local
auth
NO
YES
AC
shares SSD
with visited
VLR
YES
Home
authentication
Local
authentication
18
Figure 4-1: Home versus local
authentication
19
20
24
As illustrated to the right, if either of the two requirements are not met, authentication must
be performed by the home system. The visited system can inform the home system of its
ability to support local authentication using the TIA-41 SystemCapabilities (SYSCAP)
parameter.
25
4.1 Authentication by home system
21
22
23
26
27
28
29
To support home system based authentication, parameters and authentication signatures
must be relayed between the visited and home systems using TIA-41 messages. The figure
below illustrates the path of signaling when the roamer’s home system performs
authentication.
A-key
A-key
MSC
VLR
SS7
HLR
AC
SSD
COUNT
SSD
COUNT
Home System
Visited System
30
31
Figure 4-2: Authentication by home system
32
While home system based authentication works, it is not efficient. In the case of global
challenges which are often performed on every system access attempt (e.g. registration,
33
CDG #138, Rev 0.34
February 12, 2016
15
CDMA Authentication
Home versus local authentication
5
origination, termination, data burst, etc…), home system based authentication results in a
large amount of unnecessary SS7 signaling traffic between home and visited systems and
burdens the home AC with generating the authentication signature for each challenge
attempt. Of particular concern is the increased signaling traffic inherent in this approach
because it directly results in additional costs to carriers and call delays to roamers.
6
4.2 Local authentication by visited system
1
2
3
4
7
8
9
10
11
12
13
14
15
16
17
18
21
22
23
24
25
The
more
common
approach
to
authenticating roamers in a visited system
involves the home AC sharing SSD with a
visited VLR so that authentication may be
performed locally. Once SSD has been
shared with the visited VLR, authentication
may be performed by the visited system
without involving the home system.
Illustrated to the right, this approach
distributes authentication closer to the
roamer while disburdening the home AC and
reducing network signaling and call delays.
A-key
MSC
VLR
SSD
COUNT
SSD
COUNT
Visited System
19
20
Figure 4-3: Local authentication
Authentication signaling between the home and visited systems occurs during the initial
system access attempt (i.e. registration) before SSD and COUNT have been shared to
enable local authentication. However, once enabled, subsequent authentication attempts
are performed locally as illustrated in the above figure for the duration of time that the
roaming MS is registered in the visited network.
29
Note that the home system is not shown in the above figure since, once SSD has been
shared, local authentication does not require involvement from the home system. However,
in the event that a roaming MS were to fail local authentication, the visited system would
provide the home system with an authentication failure report (i.e. AFREPORT message).
30
4.3 SystemCapabilities (SYSCAP) of visited system
26
27
28
31
32
33
34
35
36
37
38
39
40
In order for a visited system to support local authentication, the VLR in this system must be
capable of supporting the CAVE algorithm and sharing SSD. These capabilities allow the
visited system to locally generate authentication signatures to compare against ones
received from the MS. The capability of the visited system to support the CAVE algorithm
and share SSD are indicated to a roamer’s home system via the SystemCapabilities
(SYSCAP) parameter.
SYSCAP is a required parameter in the AuthenticationRequest (AUTHREQ) message sent
from the visited network to the roamer’s home network. Therefore, when a roaming MS first
attempts to access a visited system with global challenges enabled, the home system is
notified of the system capabilities of the visited system via the AUTHREQ. If SYSCAP
CDG #138, Rev 0.34
February 12, 2016
16
CDMA Authentication
1
2
3
4
Home versus local authentication
indicates that the visited network is capable of local authentication, the home system may
enable SSD sharing by including SSD in the AUTHREQ response message (authreq) to
allow subsequent system access attempts by the roaming MS in this visited system to be
authenticated locally.
10
SYSCAP is also a required parameter in authentication report messages (i.e. ASREPORT or
AFREPORT) sent from the visited system to the home system to indicate the result of an
authentication attempt. If SYSCAP indicates that the visited network is capable of local
authentication, the home system may enable SSD sharing by including SSD in the
authentication report response message (i.e. asreport or afreport) to allow subsequent
authentication challenges to the roaming MS in this visited system to be performed locally.
11
4.4 Enabling and disabling local authentication
5
6
7
8
9
12
13
14
15
16
The home system enables local authentication by “sharing” SSD with the visited VLR. Note
that while SSD is shared by the home system, the A-key is not. This approach protects the
A-key since it is never transmitted to the visited network and provides an extra layer of
security since the home system may initiate an SSD update process at any time if SSD is
believed to have been compromised.
20
Local authentication may be enabled or disabled (i.e. sharing of SSD information invoked or
revoked with the visited VLR) using any one of the following messages sent from the home
system to the visited system. Note that this occurs independently for each roaming MS, not
for the entire visited system.
21
4-1: Messages that may be used to enable or disable local authentication
17
18
19
Message
AUTHDIR
authreq
asreport
afreport
22
23
24
25
26
27
28
29
30
31
32
Description
AuthenticationDirective Invoke message
AuthenticationRequest Return Result
AuthenticationStatusReport Return Result
AuthenticationFailureReport Return Result
To enable local authentication (i.e. invoke sharing of SSD), the home system includes an
SSD parameter in one of the above messages sent to the visited system. If the
CallHistoryCount (COUNT) mismatch mechanism is being used for clone detection, a
COUNT parameter will also be included so that both SSD and COUNT are shared with the
visited system.
To disable local authentication (i.e. revoke sharing of SSD), the home system includes the
SSDNotShared (NOSSD) parameter in one of the above messages sent to the visited
system. If the COUNT mismatch mechanism is being used, COUNT will also have been
shared. Because the home system needs to retrieve this COUNT value from the visited
system, the AUTHDIR message is typically used to turn off SSD (and COUNT) sharing. Use
of AUTHDIR to revoke sharing is simply more efficient because COUNT may be included in
CDG #138, Rev 0.34
February 12, 2016
17
CDMA Authentication
1
2
3
4
5
Home versus local authentication
the AUTHDIR Return Response (authdir) from the visited network. Since there is no
response to authdir, asreport, or afreport return response messages, use of these messages
to turn off sharing would require an additional message transaction involving a
CountRequest (COUNTREQ) from home to visited system and COUNTREQ Return
Response (countreq) from visited to home system to retrieve the COUNT value.
CDG #138, Rev 0.34
February 12, 2016
18
CDMA Authentication
Global Challenges
5. Global Challenges
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Global challenges are used by systems to
ensure that all mobile stations attempting to
access the system are authenticated.
Mobile stations that roam into visited
systems with global challenge enabled are
requested
to
provide
authentication
parameters. The visited system indicates
this request by setting the authentication bit
(i.e. AUTH=1) in the overhead message
train (OMT). The OMT should also include
the global random challenge value (RAND)
to be used in generating the authentication
result.
Visited
System
overhead message train
AUTH=1, RAND
15
16
Figure 5-1: Global challenge to MS
19
In response to the global challenge indicated by AUTH=1, authentication-capable mobile
stations will include the following authentication parameters in system access messages to
allow themselves to be authenticated in the visited network.
20
5-1: Authentication parameters provided by MS when global challenges are required
17
18
Parameter
Description
AUTHR
Authentication signature value calculated by the MS
RANDC
Most significant 8 bits of the 32-bit RAND used to calculate AUTHR
COUNT
Current call history count stored in the MS (6-bit value)
23
All system access attempts from the mobile will require these parameters to be included
when AUTH=1. System access attempts may include registration, origination, termination
(i.e. page response or reconnect), and data burst (e.g. SMS) messages.
24
5.1 Authentication signature (AUTHR)
21
22
25
26
27
28
29
The basis for authentication is the ability for both the MS and the authentication controller
(i.e. visited VLR if SSD is shared or home AC if not) to generate authentication signatures
that may be compared. In the case of a global challenge, the authentication signature is
referred to as the authentication result (AUTHR) and is calculated using the Cellular
Authentication and Voice Encryption (CAVE) algorithm with inputs illustrated below.
CDG #138, Rev 0.34
February 12, 2016
19
CDMA Authentication
Global Challenges
Random Challenge (32-bit)
32-bit RAND received in OMT. If no
RAND was received, default is zero.
ESN (32-bit)
ESN provisioned in MS
AUTHR (18-bit)
CAVE
algorithm
Authentication Data (24-bit)
Authentication
Signature
If origination, use the last 6 dialed
digits. Otherwise, use IMSI_S1
(i.e. last 6 digits of MIN)
Secret Data (64-bit)
SSD_A part of SSD generated using
CAVE and provisioned A-key
1
2
Figure 5-2: Generation of AUTHR for global challenge
3
8
The MS generates and includes an AUTHR value in all system access messages in the
visited network. Upon receiving the AUTHR from the MS, the visited system may proceed
with authentication locally or forward this AUTHR value to the roamer’s home network for
authentication. Whether MS response to the global challenge is authenticated by the visited
system or the roamer’s home system depends on whether SSD is shared with the visited
VLR.
9
5.2 Roamer authenticated by its home system
4
5
6
7
10
11
12
13
If SSD is not shared with the visited system, the AUTHR value returned by the MS and the
RAND value used by the MS to generate this AUTHR must be forwarded to the roamer’s
home system for authentication. The global challenge message flow is illustrated below for
the case in which SSD information is not shared with the visited VLR.
SSD
SSD
Home
HLR/AC
Visited
System
overhead message train
AUTH=1, RAND
system access
AUTHR, RANDC, COUNT
AUTHREQ
AUTHR, RAND, COUNT
authreq
14
15
Figure 5-3: Global challenge message flow when SSD is not shared
CDG #138, Rev 0.34
February 12, 2016
20
CDMA Authentication
Global Challenges
5
Note that the RAND, not the RANDC, is forwarded to the home system. The RAND value,
which was selected by the visited system, was used by the MS to generate an AUTHR value
in response to the global challenge. Since the AC will need to use this same RAND to
generate an AUTHR value to compare to the one received from the MS, the RAND is
included in the AUTHREQ message sent to the home system.
6
5.3 Roamer authenticated locally by the visited system
1
2
3
4
7
8
9
10
11
12
13
If SSD is shared with the visited VLR, forwarding RAND and AUTHR information to the
roamer’s home system for authentication is unnecessary. Because the visited system has
the SSD required to generate an AUTHR value locally to compare to the one received from
the MS, authentication can be performed by the visited system without involving the
roamer’s home system.
A global challenge message flow is illustrated below for the case in which SSD information is
shared with the visited VLR.
SSD
SSD
Visited
System
overhead message train
AUTH=1, RAND
system access
AUTHR, RANDC, COUNT
14
15
16
17
18
19
20
21
22
23
24
25
Figure 5-4: Global challenge message flow when SSD is shared
5.4 Pre-validation using RANDC
The RANDC consists of the 8 most significant bits of the RAND and is used by the base
station to pre-validate 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 on the OMT. 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).
CDG #138, Rev 0.34
February 12, 2016
21
CDMA Authentication
1
2
3
4
5
6
7
8
9
10
11
Global Challenges
5.5 Clone detection using COUNT
CallHistoryCount (COUNT) is a counter value maintained by the roaming MS, home AC,
and, if local authentication is enabled, the visited VLR. Used during the global authentication
process, this counter provides a mechanism for detecting cloned mobile stations, especially
when SSD and/or A-key values have been compromised.
When a system access message is received in the visited system, the COUNT value
provided by the roaming MS is compared with the one maintained by the authentication
controller to determine whether they are consistent. A mismatch suggests that a clone may
exist but is not necessarily a conclusive indication of cloning since RF transmission issues
may result in occasional minor mismatches. However, there should not be a large delta
between these values.
14
The policies of the authentication controller will determine whether to allow access, issue a
unique challenge, or deny access based on a COUNT mismatch. However, cases of large
discrepancies or repeated mismatches should be treated as indications of cloning fraud.
15
5.5.1 Updating CallHistoryCount (COUNT)
16
COUNT is updated (i.e. incremented) by the home AC according to an internal algorithm.
This algorithm typically updates the value at irregular intervals rather than simply
incrementing it with each call. To initiate an update, the AC sends an TIA-41 UpdateCount
parameter to the visited system as illustrated below.
12
13
17
18
19
Home
HLR/AC
Visited
System
AUTHDIR
UpdateCount
parameter update
parameter update confirm
authdir
COUNT
20
21
Figure 5-5: COUNT update process
22
Similar to the RANDSSD parameter used to initiated the SSD update procedure, the
UpdateCount parameter may be included by the home AC in any of the following messages
sent to the visited system to initiated the COUNT update procedure:
23
24
CDG #138, Rev 0.34
February 12, 2016
22
CDMA Authentication
1
Global Challenges
5-2: Messages that may contain UpdateCount to initiate COUNT update process
Message
AUTHDIR
authreq
asreport
afreport
2
3
4
5
6
7
8
Description
AuthenticationDirective Invoke message
AuthenticationRequest Return Result
AuthenticationStatusReport Return Result
AuthenticationFailureReport Return Result
5.6 Reporting of results to roamer’s home system
If SSD is shared with the visited network and the MS fails the global challenge, an
AuthenticationFailureReport Invoke (AFREPORT) message will be sent by the visited
system to inform the roamer’s home system of the failure as illustrated below. Reports of
successful global challenges in the visited network are unnecessary. Likewise, results of
global challenges when SSD is not shared need not be reported since the home system is
the one performing the authentication.
Global challenge
No
Authentication is
performed by the
home system so no
reporting is needed
SSD
Shared
Yes
Fail
Auth Success
Result
AFREPORT
no report
9
10
Figure 5-6: Authentication reporting for unique challenges
11
CDG #138, Rev 0.34
February 12, 2016
23
CDMA Authentication
Unique Challenges
6. Unique Challenges
1
2
3
4
5
6
7
8
9
10
11
Unlike global challenges that require all
mobile stations to provide authentication
parameters before accessing the system,
a unique challenge is directed at a
specific
mobile
station.
Unique
challenges may be used instead of or in
addition to global challenges and may be
initiated by either visited or home
systems, regardless of whether SSD is
shared.
Visited
System
authentication challenge
RANDU
12
13
Figure 6-1: Unique challenge to MS
16
Roaming mobile stations being uniquely challenged in a visited system will receive a unique
challenge message as shown above. This message may be received over paging, access,
or dedicated traffic channels.
17
6.1 Authentication signature (AUTHU)
14
15
18
19
20
21
22
23
24
As with the global challenge, the basis for authentication is the ability for both the MS and
the authentication controller (i.e. visited VLR or home AC) to generate authentication
signatures that may be compared. In the case of a unique challenge, the authentication
signature is referred to as the AuthenticationResponseUniqueChallenge (AUTHU) and is
calculated using the CAVE algorithm with inputs illustrated below. Note that the inputs used
in generating AUTHU for unique challenges differ from the inputs used in generating AUTHR
for global challenges.
Random Challenge (32-bit)
24-bit RANDU received in unique
challenge message + 8-bit IMSI_S2
ESN (32-bit)
ESN provisioned in MS
Authentication Data (24-bit)
CAVE
algorithm
IMSI_S1 (i.e. last 6 digits of MIN)
AUTHU (18-bit)
Authentication
Signature
Secret Data (64-bit)
SSD_A part of SSD generated using
CAVE and provisioned A-key
25
26
Figure 6-2: Generation of AUTHU for unique challenge
27
Upon receiving a unique challenge, the MS generates and includes an AUTHU value in a
unique challenge response message. The visited system compares the AUTHU value
28
CDG #138, Rev 0.34
February 12, 2016
25
CDMA Authentication
Unique Challenges
4
received from the MS with the AUTHU value either generated by the visited VLR or received
from the home AC to determine whether the MS is authentic. Unlike the global challenge,
comparison of AUTHU values is always performed by the visited system, even when the
challenge is initiated and AUTHU value generated by the home system.
5
6.2 Unique challenge initiated by roamer’s home system
1
2
3
6
7
8
9
10
11
12
13
A roamer’s home system may initiate a unique challenge at any time and regardless of
whether SSD has been shared with the visited VLR. In fact, even if SSD has been shared
and the visited network has successfully performed global and unique challenges on the
roamer, the home system may still initiate a unique challenge at its discretion.
If the unique challenge is initiated by the home system, the AUTHU will be generated by the
home AC and provided to the visited system in an Authentication Directive (AUTHDIR)
message
as
shown
below.
This
AUTHDIR
will
also
include
the
RandomVariableUniqueChallenge (RANDU) that was used to generate the AUTHU.
SSD
SSD
Home
HLR/AC
Visited
System
AUTHDIR
RANDU, AUTHU
authdir
authentication challenge
RANDU
auth challenge response
AUTHU
ASREPORT
unique challenge report
asreport
14
15
16
17
18
Figure 6-3: Unique challenge initiated by roamer’s home system
Because the visited system performs the comparison of AUTHU values generated by the MS
and home system, results of the unique challenge must be reported to the home system
regardless of whether the challenge succeeds or fails.
CDG #138, Rev 0.34
February 12, 2016
26
CDMA Authentication
1
2
3
4
Unique Challenges
6.3 Unique challenge initiated locally by visited system
If SSD is shared with the visited VLR, the visited system is able to initiate a unique challenge
and generate an AUTHU locally to compare to the one received from the MS. The call flow
for a visited system initiated unique challenge is illustrated below.
SSD
SSD
SSD
Home
HLR/AC
Visited
System
authentication challenge
RANDU
auth challenge response
AUTHU
AFREPORT
unique challenge report
asreport
Failure report
is only sent if
the unique
challenge fails
5
6
Figure 6-4: Unique challenge initiated by visited system
7
Note that when initiated by the visited system, results of a unique challenge only need to be
reported to the home system if the challenge fails; otherwise, the home system is not
involved in the authentication attempt.
8
9
10
11
12
13
14
15
6.4 Reporting results to roamer’s home system
When a roamer’s home system initiates a unique challenge, the visited system will send an
AuthenticationStatusReport Invoke (ASREPORT) message upon completing the challenge
attempt to inform the home system whether the authentication was successful. However,
when unique challenges are initiated locally by the visited system, the home system only
needs to be informed of failed authentication attempts as illustrated below.
CDG #138, Rev 0.34
February 12, 2016
27
CDMA Authentication
Unique Challenges
Unique challenge
Home System
Success or
Failure
ASREPORT
Visited System
Challenge
initiated by
Fail
Auth
Result
AFREPORT
Success
no report
1
2
Figure 6-5: Authentication reporting for unique challenges
3
CDG #138, Rev 0.34
February 12, 2016
28
CDMA Authentication
1
2
3
4
5
6
7
8
9
10
Updating Shared Secret Data (SSD)
7. Updating Shared Secret Data (SSD)
The SSD update process allows new SSD information to be generated by both the home AC
and roamer’s MS. 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. The SSD update process also allows
roaming carriers that share SSD with their roaming partners to reduce security concerns by
periodically changing SSD information.
Depending upon manufacturer, an AC may provide multiple mechanisms for initiating SSD
updates. These methods include automatic triggering based on a carrier defined algorithm,
periodic triggering based on a carrier defined interval, and manual triggering as needed.
17
The home 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, which may be in either idle or
traffic state. The home system may include the RANDSSD parameter in any of the following
messages sent to the visited system:
18
7-1: Messages that may contain RANDSSD to initiate SSD update process
11
12
13
14
15
16
Message
AUTHDIR
authreq
asreport
afreport
19
20
21
22
23
24
25
26
27
28
29
30
Description
AuthenticationDirective Invoke message
AuthenticationRequest Return Result
AuthenticationStatusReport Return Result
AuthenticationFailureReport Return Result
The SSD update process involves two authentication challenges. The first is a base station
challenge 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.
From the perspective of the roaming MS, the SSD update process is the same whether SSD
is shared with the visited system or not. The difference is that the non-shared scenario
places the burden of generating the AUTHU value and processing the base station
challenge on the home system and requires additional signaling between home and visited
systems. Most carriers prefer to share SSD with their roaming partners.
CDG #138, Rev 0.34
February 12, 2016
29
CDMA Authentication
1
2
3
4
5
6
7
8
Updating Shared Secret Data (SSD)
7.1 SSD update process when SSD is shared
In the shared SSD scenario, the new SSD value generated by the home AC is provided to
the visited VLR along with the RANDSSD to initiate the update to the MS. The visited VLR
uses this new SSD value to process base station and unique challenges during the SSD
update process. Once these challenges are complete, the visited network sends an
ASREPORT message containing SSD update and unique challenge reports to the home
system to indicate the outcome of the SSD update process. The following diagram
illustrates this process when SSD is shared with the visited network.
SSD
Visited
System
SSD
Home
HLR/AC
AUTHDIR
RANDSSD, SSD
SSD update
RANDSSD
authdir
base station challenge
RANDBS
SSD
Home system initiates
SSD update process by
including RANDSSD and
shares new SSD value
with the visited VLR.
MS initiates a challenge
before updating its SSD
to ensure that the update
process is being initiated
by a legitimate source.
challenge response
AUTHBS
SSD update
success
MS updates its SSD
unique challenge
RANDU
Unique challenge is used
to validate the new SSD
generated by the MS.
challenge response
AUTHU
ASREPORT
SSDURPT, UCHALRPT
asreport
Reports sent back to
home system to indicate
outcome of SSD update
and unique challenge
9
Figure 7-1: SSD update process when SSD is shared
10
11
12
13
14
15
16
7.2 SSD update process when SSD is not shared
There are two major differences in the SSD update process when SSD is not shared with the
visited system. The first is that the home system, not the visited system, selects the RANDU
and generates the AUTHU required to perform the unique challenge during the SSD update
process. These RANDU and AUTHU values are included along with the RANDSSD when
the SSD update is initiated. The second is that rather than being processed locally by the
CDG #138, Rev 0.34
February 12, 2016
30
CDMA Authentication
1
2
Updating Shared Secret Data (SSD)
visited system, the base station challenge from the MS is forwarded to the home system.
These differences are highlighted in red text in the following diagram illustrating.
SSD
Home
HLR/AC
Visited
System
AUTHDIR
RANDSSD,
RANDU, AUTHU
update SSD
RANDSSD
base station challenge
RANDBS
challenge response
AUTHBS
authdir
BSCHALL
RANDBS
bschall
AUTHBS
SSD update
success
SSD
Home system initiates
SSD update process by
including RANDSSD and
provides RANDU and
AUTHU values to enable
visited system to perform
unique challenge.
MS initiates a challenge
before updating its SSD
to ensure that the update
process is being initiated
by a legitimate source.
This challenge is
forwarded to the home
system to be processed.
MS updates its SSD
unique challenge
RANDU
Unique challenge is used
to validate the new SSD
generated by the MS.
challenge response
AUTHU
ASREPORT
SSDURPT, UCHALRPT
asreport
Reports sent back to
home system to indicate
outcome of SSD update
and unique challenge
3
4
Figure 7-2: SSD update process when SSD is not shared
5
6
CDG #138, Rev 0.34
February 12, 2016
31
CDMA Authentication
Authentication Enhancements
8. Authentication Enhancements
1
4
IS-778 defines various enhancements to the CAVE-based authentication mechanisms
introduced in TIA-41-D. These enhancements have since been incorporated into TIA-41-E
and include the following:
5
8-1: Authentication enhancements in IS-778
2
3
Enhancement description
- Count update after handoff
- Ability to obtain subscriber profile before authentication on initial access
- Handling of suspicious call originations
- Identification of the serving MSC when providing an authentication report
- Handling of authentication-capable MS’s from non-capable home systems
6
7
8
9
10
11
12
13
14
15
16
17
Except for the introduction of a new SuspiciousAccess parameter, IS-778 authentication
enhancements leverage the same TIA-41-D authentication operations (e.g. AUTHDIR,
AUTHREQ, etc…) and parameters. Details on selected authentication enhancements
introduced in IS-778 are provided in the following subsections.
8.1 Roamers from a non-authentication-capable partner
When an authentication-enabled visited system attempts to support inbound roamers from a
non-authentication-capable home system, the home system is neither able to provide an
AuthenticationCapability (AUTHCAP) parameter indicating that authentication is not required
nor recognize an AUTHREQ message from the visited system. As a result, the
authentication-enabled visited system receives AUTHREQ Return Error of “Operation Not
Supported” during registration of a roaming MS from the non-authentication-capable home
system.
22
In TIA-41-D this error is treated as an authentication failure and the roamer is not able to
access the visited system. TIA/EIA-E addresses this scenario by modifying the behavior of
the visited MSC to proceed with registration and not attempt subsequent authentications with
the roamer’s home network. This TIA-41-E behavior is necessary if an authenticationenabled system wishes to support roamers from a non-authentication-capable system.
23
8.2 Handling of suspicious call origination attempts
18
19
20
21
24
25
26
The new SuspiciousAccess (SUSACC) parameter is provided as a mechanism to allow a
visited system to inform a home system when their roamer’s call origination attempt in the
visited system is suspicious. When a suspicious access is identified, the SUSACC
CDG #138, Rev 0.34
February 12, 2016
33
CDMA Authentication
1
2
Authentication Enhancements
parameter is included in the AUTHREQ sent to the home system. Receipt of the SUSACC
parameter indicates to the home system that a unique challenge may be warranted.
SSD
SSD
Visited
System
Home
HLR/AC
overhead message train
AUTH=1, RAND
system access
AUTHR, RANDC, COUNT,
Digits (dialed)
AUTHREQ
AUTHR, RAND, COUNT,
SUSACC, Digits (dialed)
authreq
RANDU, AUTHU
Visited system
determines that dialed
digits are suspicious
and includes the
SUSACC parameter.
Home system
responds by initiating
a unique challenge.
3
4
Figure 8-1: Handling of suspicious access attempts
5
While the SUSACC parameter may be used to indicate an unspecified scenario in which an
access attempt appears suspicious for reasons other than anomalous dialed digits, the
primary scenario addressed by SUSACC is the receipt of extraneous digits in the number
dialed by a roamer during call origination. These extraneous digits could indicate a replay
attack that is attempting to circumvent global challenge authentication by appending
previously dialed digits to a new dialed number.
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Global challenges are generally an effective tool against replay attacks since call origination
attempts use the last 6 digits of the dialed number to calculate the AUTHR value. One
would think it unlikely for a replay attempt to be useful since the fraudulent user could only
successfully pass authentication by dialing numbers ending in the same 6 digits. However, it
may be possible to circumvent the spirit of this limitation by appending the last 6 dialed digits
from the original attempt to the dialed number in the fraudulent replay attempt. While this
results in a dialed number that is 6 digits longer than it should be, when the dialed digits are
processed through the MSC translation tables, a route would be determined based on the
new dialed number before reaching these additional digits. Once the route is determined,
the MSC often ignores the remaining digits. The SUSACC parameter allows the MSC to
identify these additional digits as suspicious rather than ignoring them.
If SSD is shared with the visited VLR, an alternative approach could be to ensure that the
visited MSC policy triggers a locally initiated unique challenge when additional digits are
provided.
CDG #138, Rev 0.34
February 12, 2016
34
CDMA Authentication
Over-The-Air (OTA) Support
9. Over-The-Air (OTA) Support
1
6
MAP support for Over-The-Air Service Provisioning (OTASP) was introduced in IS-725 with
support for Over-The-Air Parameter Administration (OTAPA) added in IS-725-A.
OTASP/OTAPA support in IS-725-A was later incorporated into TIA-41-E. The purpose of
this section is to provide basic information on these mechanisms in the context of their
support for authentication functions (e.g. A-key provisioning).
7
9.1 OTASP
2
3
4
5
17
Over-The-Air Service Provisioning (OTASP) provides carriers with a flexible and secure
mechanism to support activation of service for new subscribers and updating of MS
provisioning information (e.g. A-key value, NAM programming, etc…) for existing subscribers
over the air interface. OTASP involves the subscriber initiating these actions by placing an
OTASP call to the Customer Service Center (CSC) from their MS. This call is typically
invoked by entering an OTASP feature code such as *228, followed by additional
information such as a system code, directory number, or system operator code. The dialing
format used to invoke an OTASP call is determined by the carrier. OTASP provides
subscribers with flexibility since they may activate or update their MS provisioning at any
time by simply placing a call rather than having to physically visit a service center.
18
9.2 OTAPA
8
9
10
11
12
13
14
15
16
27
Over-The-Air Parameter Administration (OTAPA) is similar to OTASP in that it supports
updating of NAM and other operational parameters in the MS over the air interface.
However, OTAPA is initiated autonomously by the network without involvement from the
subscriber. In fact, the subscriber is unaware of OTAPA updates when they occur. OTAPA
may be performed at anytime while the MS is powered on and does not interfere with the
subscriber’s use of the MS (i.e. if the subscriber attempts to use the MS while OTAPA is in
progress, the OTAPA is terminated). OTAPA provides carriers with flexibility since they may
update subscriber MS provisioning when needed without requiring the subscriber to take any
action.
28
9.3 OTASP/OTAPA mechanism
19
20
21
22
23
24
25
26
32
OTASP and OTAPA operations are controlled by an Over-The-Air Function (OTAF) that
communications via TIA-41 with the serving MSC and home HLR/AC. In the case of
OTASP, the OTAF also communicates with the Customer Service Center (CSC) via
proprietary messaging.
33
9.3.1 OTASP attachment
34
Because OTASP supports the activation of new mobile stations that have not been
provisioned, two things must occur at the serving MSC. First, since the MS may not be
29
30
31
35
CDG #138, Rev 0.34
February 12, 2016
35
CDMA Authentication
1
2
3
4
5
Over-The-Air (OTA) Support
provisioned with an A-key, the MSC may need to allow unauthenticated OTASP calls to be
routed to their home customer service centers. Second, the MSC must recognize the call as
an OTASP call and assign a TemporaryReferenceNumber (TRN) to be included with the call
(typically as the calling party number) when it is routed to the CSC. The OTAF uses this
TRN to create as attachment between itself and the MSC as illustrated below.
OTAF
Visited
System
CSC
call origination
OTASP FC + XX
MSC recognizes OTASP
call attempt, selects
TRN, and routes call to
CSC with TRN in either
the calling or called party
number
ISUP call (TRN)
Voice path connected
SMDPP
MIN, TRN,
ACTCODE, SRVIND
proprietary
TRN
smdpp
MS_MSID, ESN,
MSCID, SYSCAP
SMDPP
ACTCODE, MIN,
ESN, SRVID
smdpp
CSC provides received
TRN to OTAF. OTAF
selects a MIN and
initiates attachment by
sending SMDPP with
action code set to
“Attach MSC to OTAF”.
MSC responds with MS
and MSC information
Attachment now setup.
OTAF sends SMDPP
with action code set to
“Release TRN” since
TRN no longer needed.
6
7
Figure 9-1: OTASP attachment between MSC and OTAF
8
In the case of OTAPA, this attachment process is not required since the MS has already
been provisioned.
9
10
9.3.2 Action codes
11
Each OTASP/OTAPA operation involves the OTAF sending an OTASPRequest
(OTASPREQ) message to the HLR/AC. In the case of an OTASP operation, the sending of
this message is a response to proprietary messaging with the CSC once a subscriber has
been connected to the CSC. In the case of an OTAPA operation, the trigger is defined by
the carrier without involvement from the subscriber. In either case, the OTASPREQ
message contains an ActionCode (ACTCODE) parameter that identifies the desired action to
be performed during the OTASP/OTAPA operation. New action codes defined in TIA-41-E
are shown below.
12
13
14
15
16
17
18
CDG #138, Rev 0.34
February 12, 2016
36
CDMA Authentication
Over-The-Air (OTA) Support
9-1: New action codes defined in TIA-41-E
1
OTASP actions
- Attach MSC to OTAF
- Initiate RegistrationNotification
- Generate Public Encryption values
- Generate A-key
- Perform SSD Update procedure
- Perform re-authentication procedure
- Release TRN
- Commit A-key
- Release Resources (e.g., A-key, Traffic Channel)
- Record NEWMSID
- Allocate Resources (e.g., Multiple message traffic channel delivery)
- Generate Authentication Signature
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
9.4 A-key generation procedure
While OTASP and OTAPA may be useful for a variety of scenarios, this paper is interested
in their use in the context of authentication. A primary use of these functions is that of an
alternative to the A-key provisioning options discussed in section 3.2 A-key provisioning.
While these previously discussed options are functional, each suffer from deficiencies in
either flexibility or security.
For example, while pre-programmed A-keys from the manufacturer are secure, they are
inflexible without a mechanism to update the A-key if necessary. A-keys may be updated at
designated service centers, but this approach lacks flexibility since it requires the customer
to bring their MS to the service center. On the other hand, more flexibility may be provided
by allowing customers or retailers to provision A-key values, but this approach lacks security.
The A-key generation procedure supported by OTASP addresses each of these issues. Its
ability to be initiated by the subscriber at anytime provides flexibility while its use of a 512-bit
Diffie-Hellman key agreement algorithm for secure key exchange provides security. The
following illustrations provide a high-level view of the A-key generation procedure and call
flow for this procedure once an attachment has been made between the serving MSC and
OTAF.
CDG #138, Rev 0.34
February 12, 2016
37
CDMA Authentication
Over-The-Air (OTA) Support

OTAF attaches call to serving MSC using TRN and controls
A-key generation procedure using OTASPREQ messages
to the AC and SMDPP messages to the serving MSC
Partial
keys
Partial
keys
Generate
A-key

Partial
keys
OTAF
AC

Customer
Care
Generate
A-key
MS and AC each locally
generate same A-key
(actual A-key value is
never transmitted)
Subscriber dials OTASP feature code from the MS
that needs to be activated. MSC assigns a TRN
and routes the call to the MS’s customer care.
1
2
CDG #138, Rev 0.34
Figure 9-2: OTASP A-key generation procedure
February 12, 2016
38
CDMA Authentication
Over-The-Air (OTA) Support
OTAF
Visited
System
HLR/AC
OTASPREQ
ACTCODE, AKEYPV
otaspreq
AKEYPV, MODVAL,
PRIMVAL, BSKEY
SMDPP SMS_BearerData
(MS Key Request), SVIND
MS key request
MS key response
smdpp SMS_BearerData
(MS Key Response)
SMDPP SMS_BearerData
(Key Generation Request, SVIND)
key generation request
key generation response
smdpp SMS_BearerData
(Key Generation Response)
OTASPREQ
MSKEY, ACTCODE
otaspreq
1
Figure 9-3: A-key generation call flow
2
3
4
5
6
7
8
9
10
11
12
13
14
15
9.5 SSD update
In addition to A-key generation, the OTAF may initiate the SSD update procedure discussed
in the 7. Updating Shared Secret Data (SSD) section of this paper. The OTAF begins the
SSD update procedure by sending an OTASPREQ message containing an ACTCODE set to
“Perform SSD Update procedure” to the HLR/AC. Also included in this OTASPREQ
message is an SRVIND parameter indicating either OTASP or OTAPA.
As illustrated below, upon receiving the OTASPREQ, the HLR/AC proceeds with the SSD
update procedure as normal. The only difference in SSD update call flow when this
procedure is initiated by the OTAF is that each TIA-41 invoke message between HLR/AC
and MSC during the procedure includes the SRVIND parameter indicating OTASP or
OTAPA. Also note that shared SSD is not supported for OTASP/OTAPA sessions.
Therefore, new SSD is not included in the AUTHDIR sent to the visited system during an
OTAF-initiated SSD update.
CDG #138, Rev 0.34
February 12, 2016
39
CDMA Authentication
Visited
System
Over-The-Air (OTA) Support
HLR/AC
OTAF
OTASPREQ
MS_MSID, ACTCODE,
SYSCAP, MSCID, SRVID
AUTHDIR
RANDSSD, RANDU, AUTHU,
SRVIND, MS_MSID, MSCID
Call flow proceeds as illustrated in Figure 7-2:
SSD update process when SSD is not shared.
otaspreq
SSDURPT, UCHALRPT
OTAF sends an OTASPREQ
message with action code set
to “Perform SSD Update “
HLR/AC proceeds with SSD
update procedure as normal.
SRVIND, MS_MSID, and
MSCID received from OTAF
are included in the AUTHDIR.
Messages between MSC and
AC during the procedure will
include the SRVIND.
To complete the SSD update,
HLR/AC responds to the
OTASPREQ and includes the
SSD update and challenge
reports received from the MSC.
1
2
CDG #138, Rev 0.34
Figure 9-4: OTAF-initiated SSD update procedure
February 12, 2016
40
CDMA Authentication
10. Recommendations
1
2
Recommendations
10.1 A-key management recommendations
6
A fundamental rule of A-key management in CDMA authentication is that allowing anyone
access to the A-key creates potential for its fraudulent usage. The potential for exposing the
A-key exists anytime it is transferred into or out of the AKMS. With this in mind, the following
recommendations are offered.
7
10.1.1 Protect A-key information between manufacturer and AKMS
8
10
If pre-programmed A-keys are used, ESN/A-key pairs should be securely transferred from
the manufacturer’s database subsystem to the carrier’s AKMS. For more information, refer
to 3.1.1 A-key generated by manufacturer.
11
10.1.2 Protect A-key information between AKMS and AC
12
13
The AC should be able to securely retrieve A-keys directly from the AKMS.
information, refer to 3.2.1 Provisioning the AC.
14
10.1.3 Protect A-key information between AKMS and MS
15
17
Secure and non-intrusive methods such as pre-programmed A-keys, programming devices
that communicate directly with the AKMS, or OTASP are recommended for provisioning the
MS. For more information, refer to 3.2.2 Provisioning the MS.
18
10.1.4 Delete A-keys from the AKMS once provisioned into MS and AC
19
20
This is simply an aging principle that prevents sensitive data from being unnecessarily stored
in multiple places.
21
10.2 General authentication recommendations
3
4
5
9
16
For more
24
Whether authentication must be enforced by the visited network should be agreed upon and
specified in the roaming agreement between roaming partners.
The following
recommendations are offered for authentication:
25
10.2.1 Use global challenges
26
Global challenges provide rapid authentication of any roaming MS attempting to access the
visited network. For more information, refer to 5. Global Challenges.
22
23
27
CDG #138, Rev 0.34
February 12, 2016
41
CDMA Authentication
Recommendations
1
10.2.2 Use the COUNT mismatch mechanism
2
4
Validation of COUNT during global challenge authentication provides a mechanism for
detecting cloned mobile stations, especially when SSD and/or A-key values have been
compromised. For more information, refer to 5.5 Clone detection using COUNT.
5
10.2.3 Enable local authentication
6
8
Local authentication reduces signaling between the home and visited systems and
minimizes call setup delay during authentication. For more information, refer to 4.2 Local
authentication by visited system.
9
10.2.4 Perform an SSD update when activating a new MS
3
7
13
Explicitly performing an SSD update whenever new mobile stations are activated will ensure
that any MS with a default SSD value of zero is updated with an SSD value based on the
ESN, A-key, and RANDSSD. For more information on the SSD update process, refer to 7.
Updating Shared Secret Data (SSD).
14
10.2.5 Trigger fraud procedures on large or repeated COUNT mismatches
15
17
While a COUNT mismatch does not definitively indicate that an MS is a clone, large
discrepancies or repeated mismatches should trigger fraud procedures.
For more
information, refer to 5.5 Clone detection using COUNT.
18
10.2.6 Trigger a unique challenge when a cloned MS is suspected
19
21
If a cloned MS is suspected even after a successful global challenge, the unique challenge
mechanism allows the specific MS to be challenged to ensure that it possess correct SSD.
For more information, refer to 6. Unique Challenges.
22
10.2.7 Trigger an SSD update if cloning still suspected after unique challenge
23
26
If a cloned MS is still suspected after a successful unique challenge, the SSD update
process should be used to limit the carrier’s exposure in case the MS is a clone using valid
SSD and/or A-key information. For more information on the SSD update process, refer to 7.
Updating Shared Secret Data (SSD).
27
10.2.8 Ensure that roaming partner denies service if authentication fails
28
While this may sound self-evident, many equipment manufacturers provide carriers with a
configurable field to either deny or allow service to a user when authentication fails. If
authentication fails, service should be denied.
10
11
12
16
20
24
25
29
30
CDG #138, Rev 0.34
February 12, 2016
42
CDMA Authentication
Recommendations
1
10.3 Specific recommendations for identified scenarios
2
10.3.1 Cloned MS – valid ESN and MIN
3
4
5
6
7
8
9
A cloned MS is one that has been illegally programmed with ESN and MIN information
associated with a legitimate subscriber. Because this subscriber information is sent overthe-air, it is susceptible to being intercepted by fraudsters using devices such as Cellular
Cache Boxes that combine a scanner, computer, and mobile station. While the CDMA air
interface makes this information much more difficult to intercept, many CDMA phones
support the ability to switch down into analog (e.g. AMPS) mode to enhance coverage area.
When in analog mode, legitimate subscriber information is quite easily intercepted.
12
Use of the global challenge authentication mechanism by a carrier will thwart the efforts of
fraudsters using cloned mobile stations. In a roaming scenario, insistence upon the use of
authentication by each roaming partner protects both visited and home systems.
13
10.3.2 Cloned MS – valid ESN, MIN, and SSD
10
11
14
15
16
17
Beyond the common scenario of a cloned MS using illegally obtained ESN and MIN
information is the scenario in which SSD has been compromised. If a cloned MS acquires
validated SSD associated with a legitimate MS, both the legitimate and the cloned MS will be
able to access the system.
24
The solution is the use of the SSD update process discussed in the 7. Updating Shared
Secret Data (SSD) section of this paper. Because only the legitimate MS possess a valid Akey, only this legitimate MS will be able to generate a new SSD value that is valid.
Therefore, the SSD update process provides an effective way for the home carrier to deny
access to cloned mobile stations that are illegally using validated SSD information. Further,
because this process is transparent to users, the goal is accomplished without impacting the
user experience of legitimate subscribers.
25
10.3.3 Cloned MS – valid ESN, MIN, SSD, and A-key
18
19
20
21
22
23
26
27
28
29
30
31
32
33
34
35
36
37
A more problematic scenario may exist when an older MS that uses a removable EEPROM
to store authentication parameters is supported. Because the contents of this EEPROM,
including the A-key, can be read and copied with relative ease, a clone can be created that
is an exact working copy of the legitimate MS. In such a case, both the legitimate and the
cloned MS will be able to access the system and update SSD.
While at first glance it may appear that a compromised A-key renders the SSD update
process ineffective, however, in practice, updating the SSD does actually solve the problem,
albeit in a potentially more intrusive and indirect fashion. The reason is that only one of the
two mobile stations (legitimate MS or clone) may be active at any given time. If the
legitimate MS is active when SSD update is performed, its SSD will be updated and the
clone will no longer be able to access the system. This is the best scenario as it solves the
problem without impacting the user experience of the legitimate subscriber.
CDG #138, Rev 0.34
February 12, 2016
43
CDMA Authentication
Recommendations
7
However, if the cloned MS is active when SSD update is performed, its SSD will be updated
and the legitimate subscriber will no longer be able to access the system. The legitimate
subscriber would then need to contact customer service to have a new A-key provisioned in
their MS and the clone will be deactivated. This, of course, is less desirable since it requires
the subscriber to take action to restore their service; however, it would deny further access
to the cloned MS. A prudent additional step would be to encourage subscribers to upgrade
to newer mobile stations that are less susceptible to compromising the A-key.
8
10.3.4 Replay attack with extra digits
9
Global challenges typically deter replay attacks since the global challenge mechanism uses
the last six digits of the dialed number as an input for generating the authentication
signature. The idea is that even a successful replay attack would be of little use since it
could only be used to dial other numbers that end in the same six digits. However, because
of the way in which routing-on-dialed-digits occurs in many MSCs, this mechanism may be
bypassed by appending these last six digits onto a new dialed number.
1
2
3
4
5
6
10
11
12
13
14
15
16
17
18
19
20
The solution is to support the SuspiciousAccess (SUSACC) parameter discussed in the 8.2
Handling of suspicious call origination attempts section of this paper. Use of this parameter
allows the visited system to inform the home system when a roamer’s call origination attempt
includes extraneous digits. In response the home system may use the unique challenge
mechanism to ensure that the roamer is legitimate. If the origination attempt is, indeed, a
replay attempt, this unique challenge will fail.
21
CDG #138, Rev 0.34
February 12, 2016
44
CDMA Authentication
11. AKA-based Authentication
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
AKA-based Authentication
Enhanced Subscriber Authentication (ESA) refers to 3rd generation authentication intended
to replace CAVE-based authentication currently implemented by CDMA carriers. This new
form of authentication is based on 3GPP Authentication and Key Agreement (AKA) for
UMTS. MAP support for AKA in CDMA networks is defined by IS-945 with air interface
support included in all releases following CDMA2000 Rev C. Note, however, that in order to
facilitate interoperability and allow for phased introduction of AKA among various CDMA
carriers, devices and networks that support AKA should also support legacy CAVE-based
mechanisms. IS-945 also updates authentication capabilities (AUTHCAP) and system
capabilities (SYSCAP) parameters to allow the visited and home systems to identify to one
another which forms of authentication are supported by the home system’s roaming MS and
the visited system’s MSC/VLR.
The major advantages of AKA include stronger and bilateral authentication support.
Stronger authentication is provided through the use of larger 128-bit authentication keys and
stronger SHA-1 hash function. Bilateral authentication is provided via an authentication
token passed to the MS during the AKA authentication challenge. The AKA challenge
mechanism is similar to a CAVE-based unique challenge from the perspective of the network
authenticating the MS. However, the addition of the authentication token provides the MS
with information that enables it to authenticate the network before completing the challenge.
This bilateral authentication capability prevents false base stations attacks that could disable
voice privacy or compromise private identity information.
32
While they are beyond the scope of this paper, it is worth mentioning additional security
features enabled by AKA that indicate the robust nature of AKA as a successor to CAVE.
Following the bilateral entity authentication, AKA allows for the generation of new cipher and
integrity keys (CK and IK, respectively). These 128-bit keys enable a security association
between the MS and the serving MSC for supporting advanced security services such as
signaling message data integrity, signaling information element encryption, and user data
encryption. Also generated is a 128-bit UIM authentication key (UAK) that is used to protect
against the threat of rogue mobile stations when dealing with UIMs. The MS and the home
AC each generate these keys independently. Keys generated by the home AC are provided
in authentication vectors to the visited network and are never transmitted over the air to or
from the MS.
33
11.1 Authentication vectors (AVs)
22
23
24
25
26
27
28
29
30
31
34
35
36
37
A fundamental concept in AKA is the authentication vector (AV). An AV is essentially a
group of information used for one AKA attempt. AVs are generated by the home AC and
distributed to the visited network. Each AV contains all information required by the visited
network to locally perform AKA with an AKA-enabled mobile station. To thwart replay
CDG #138, Rev 0.34
February 12, 2016
45
CDMA Authentication
1
2
AKA-based Authentication
attempts, each AV must be used for only one AKA attempt. In other words, each AKA
attempt uses a different AV. The information contained in an AV is illustrated below.
AV
Authentication Vector
RANDA
XRES
AUTN
CK, IK, & UAK
Random Challenge
Number
(128 bits)
Expected Response
(32, 64, or 128 bits)
Network
Authentication
Token
Cipher, Integrity, & UIM
Authentication Keys
(128 bits each)
CON_SQN
AMF
MAC_A
Concealed
Sequence Number
(48 bits)
Authentication
Management Field
(16 bits)
Message
Authentication Code
(64 bits)
SQN
Sequence
Number
(48 bits)

AK
Anonymity
Key
(48 bits)
3
4
Figure 11-1: Information contained in an authentication vector
5
12
Similar to a CAVE-based unique challenge when SSD is not shared, AKA challenges involve
both the random challenge number and challenge response value being generated by the
home system and provided to the visited system to enable local authentication. In CAVE,
these values (RANDU and AUTHU) are provided to the visited system as separate
parameters. In AKA these values (RANDA and XRES) are part of the AV provided to the
visited system. During the AKA attempt, random challenge number (RANDA) and network
authentication token (AUTN) information from the AV is provided to the MS by the visited
network. More information about this process is provided later.
13
11.2 AKA authentication process
6
7
8
9
10
11
14
15
16
17
18
19
Similar to CAVE, AKA relies on an authentication key associated with the MS and available
only to the MS and its home AC. In CAVE, this key is known as the authentication key (Akey). In AKA, the key is known as the master key (K).
Also similar to CAVE, AKA involves a challenge process that allows the network to
authenticate the MS. However, in AKA the information provided during this challenge also
enables the MS to authenticate the network, providing for bilateral authentication.
CDG #138, Rev 0.34
February 12, 2016
46
CDMA Authentication
1
2
3
AKA-based Authentication
The diagram below provides a high-level graphical description of the AKA process. The
purpose for this diagram is to show the concepts involved in AKA, not to identify specific
message flow.
Visited
System
Home
HLR/AC
Request AVs
Distribution
of AVs
Store the
AV list
auth request
(RANDA, AUTN)
Generate AK
Use AK to derive SQN from
CON_SQN in AUTN
Provide AV list
Select an AV from the stored list
to use with this auth attempt.
Include the RANDA & AUTN
values from this AV in the auth
request sent to the MS.
Generate XMAC_A
Does XMAC_A = MAC_A
received in AUTN?
If not…auth reject
If not…synch failure
Is SQN fresh?
Auth of network
by the MS
Failure report
Generate RES
Auth of
MS by the
network
Include RES in
auth response
auth response
(RES)
Does RES = XRES in the AV?
If not, failure report
Compute CK, IK, & UAK keys
Use CK, IK, & UAK keys from AV
Security association
established
4
5
Figure 11-2: Simplified conceptual flow of AKA authentication
6
In an attempt to simplify the overall AKA process, the diagram identifies four major phases.
The grey dashed arrows (e.g. “If not, auth reject”), indicate failure scenarios in which the
AKA attempt would not proceed and a failure report would be provided to the home system
to indicate the reason for the failure. Otherwise, each phase assumes that the previous
phase completed successfully. These phases include:
7
8
9
10
11
12
13
1. Distribution of AVs
a. Authentication vectors (AVs) are generated by the home system and
provided to the visited system in an AV list
CDG #138, Rev 0.34
February 12, 2016
47
CDMA Authentication
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
AKA-based Authentication
2. Authentication of the network by the MS
a. The message authentication code (MAC_A) received from the network is
verified against the expected MAC_A (XMAC_A) generated by the MS
b. The sequence number (SQN) received from the network is verified against
the SQN locally maintained by the MS
3. Authentication of the MS by the network
a. The authentication response (RES) received from the MS is verified against
the expected RES (XRES) received from the home system in the network
authentication token (AUTN)
4. Establishment of security association between MS and MSC
a. Cipher key (CK), integrity key (IK), and UIM authentication key (UAK) are
generated by the MS in such a way that they are identical to the ones
provided to the visited network in the AV
b. The security association between MS and MSC involves using these keys to
support security services such as confidentiality and integrity
With the exception of the last, each of these phases will be expanded upon in greater detail
in the following sections. The last phase involves the establishment of a security association
following bilateral authentication between MS and network. This last phase enables security
features such as confidentiality and integrity that are beyond the scope of this paper.
24
While the example provided above involves the AKA being initiated by the visited network, it
is worth noting that, as in the case of unique challenges in CAVE, AKA may also be initiated
by the home system at any time. To initiate AKA, a home system would simply send an
authentication directive (AUTHDIR) containing the AV to be used for the AKA attempt. Upon
receiving the AV, the visited network would proceed with the AKA attempt as normal.
25
11.3 Distribution of authentication vectors
20
21
22
23
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Since an AV may only be used once, the visited network must obtain a new AV each time
AKA is performed. With AKA potentially being performed on every system access attempt
by the MS, the process of obtaining new AVs from the home network for each AKA would
result in a significant signaling burden between visited and home systems. To prevent this
inefficiency, AKA allows the home system to generate multiple AVs and distribute these AVs
to the visited system using a single AV list parameter (AKAVL). The AVs in this list are
ordered by sequence number. The number of AVs in the list is limited by an AV count
parameter (AKAVC) provided by the visited system that indicates the maximum number of
AVs the visited system is willing to accept at one time.
Upon receiving the list of AVs from the home system, the visited system stores this list and
simply selects a new AV from the list for each subsequent AKA attempt with the MS. Since
each AKA attempt, whether successful or not, results in one AV being removed from the list,
the visited network also maintains a minimum threshold of AVs. If the number of AVs in the
list falls below this threshold, the visited network will request a new list from the home
system.
CDG #138, Rev 0.34
February 12, 2016
48
CDMA Authentication
AKA-based Authentication
Visited
System
Home
HLR/AC
Visited system doesn’t
know if MS supports
AKA so CAVE-based
global challenge is used
overhead message train
AUTH=1, RAND
system access
AUTHR, RANDC, COUNT
AUTHREQ
AUTHR, RAND, COUNT,
SYSCAP, AKAVC
SYSCAP included to
indicate AKA support by
visited system. AKAVC
used to indicate the max
number of AVs expected
authreq
AKAVL
If the MS supports AKA,
a list of AVs is provided
using AKAVL
Visited system selects
an AV from the received
list and uses it to
perform AKA auth
auth request
RANDA, AUTN
1
2
Figure 11-3: Distribution of AVs to the visited system
3
The example call flow above illustrates the distribution of an AV list to a visited network
during an initial system access attempt. Because it is the initial system access attempt (e.g.
registration), the visited system is unaware of the mobile station’s authentication capabilities.
Since support for CAVE is assumed and AKA is unknown, the visited system initiates a
CAVE-based global challenge to the MS and includes the MS response in an authentication
request (AUTHREQ) to the home system. However, also included in this AUTHREQ are
parameters to indicate that the visited system supports AKA and a request for AVs.
4
5
6
7
8
9
13
Since the home system is aware of the authentication capabilities of the MS, it may either
process the CAVE-based global challenge response (AUTHR) or return an AV list to allow
the visited system to use AKA. Returning an AV list implicitly indicates that the MS supports
AKA.
14
11.4 Authentication of the network by the MS
10
11
12
15
16
17
18
19
20
21
Authentication of the network by the MS involves an explicit validation that the home AC is
synchronized with the MS and an implicit validation that the AV information being used for
this authentication was generated by a home AC provisioned with the same master key (K)
as the MS. To ensure synchronization, a sequence number is provided by the network and
compared against the sequence number maintained by the MS. To validate the authenticity
of the message, a message authentication code (MAC_A) is provided by the network and
compared against an expected MAC (XMAC_A) computed by the MS.
CDG #138, Rev 0.34
February 12, 2016
49
CDMA Authentication
AKA-based Authentication
1
11.4.1 Sequence number (SQN)
2
To protect the integrity of the sequence number (SQN), the network conceals the SQN using
48-bit anonymity key (AK). The result is the concealed SQN (CON_MS_SQN) which is
provided to the MS in the network authentication token (AUTN). Because it is concealed,
the SQN must be derived by the MS before it can validated. To derive the SQN from the
CON_MS_SQN, the MS first generates an AK value using the f5 algorithm with inputs shown
below.
3
4
5
6
7
K (128-bit)
Provisioned in MS & AC.
RANDA (128-bit)
f5
AK
(48-bit)
Received in AV and sent to MS.
8
9
Figure 11-4: Generation of AK for AKA
10
13
Since the MS and home AC are provisioned with the same master key (K), the AK generated
by the MS will be the same as the one used by the home AC to conceal the SQN. Once this
AK has been generated, the MS derives the SQN from the CON_MS_SQN and compares
this SQN to its own.
14
11.4.2 Synchronization failure (i.e. SQN mismatch)
15
If the SQN provided by the network does not match the one maintained by the MS, a
synchronization problem exists between the network and the MS. In such a case, the MS
will respond to the authentication request with an authentication resynchronize message
(AURSYNM). To enable the network to resynchronize with the MS, the MS includes a
concealed version of its own SQN (CON_MS_SQN) as shown below. In addition to the
CON_MS_SQN, the MS also includes a message authentication code for resynchronization
(MAC_S). The purpose of the MAC_S is to allow the network to validate the authenticity of
the resynchronization request and prevent unauthorized devices from initiating
resynchronization.
11
12
16
17
18
19
20
21
22
23
CDG #138, Rev 0.34
February 12, 2016
50
CDMA Authentication
AKA-based Authentication
Visited
System
Home
HLR/AC
auth request
RANDA, AUTN
auth resynchronize
CON_MS_SQN, MAC_S
MS determines that the SQN contained in the AUTN
does not match its locally stored SQN and responds
with an auth resynchronize message
AKAREPORT
AKARPT,
RANDA, AUTS
akareport
AKAVL
auth request
RANDA, AUTN
Failure report sent with an
AKARPT value of “Synch
Failure”. AUTS contains
CON_MS_SQN & MAC_S
values received from MS
Home system uses AUTS info
to synchronize with MS and
provides a new list of AVs.
Visited system reattempts AKA
auth using AV from new list.
1
2
Figure 11-5: AKA synchronization failure (i.e. SQN mismatch)
3
Upon receiving an AURSYNM response from the MS, the visited system sends an AKA
status report (AKAREPORT) to the home system with AKARPT set to “Synchronization
Failure.” Also included in this report are the RANDA used during the AKA attempt and an
AKA authentication token for resynchronization (AUTS) containing the CON_MS_SQN and
MAC_S values received from the MS.
4
5
6
7
8
9
10
11
The home system uses the MAC_S to ensure that the resynchronization attempt is authentic
and sets its SQN to the one concealed in the CON_MS_SQN. With the new SQN, the home
system then generates a new AV list and provides this new AV list to the visited network in
the AKAREPORT response message (akareport).
13
Now that the home system has resynchronized and provided a new list of AVs, the visited
system selects an AV from the new list and reattempts AKA with the MS.
14
11.4.3 Message authentication code (MAC_A)
15
The message authentication code (MAC_A) enables the MS to authenticate the network.
Using the f1 algorithm with inputs shown below, the MS generates an expected MAC_A
(XMAC_A) value to compare to the one provided by the network in the AUTN.
12
16
17
CDG #138, Rev 0.34
February 12, 2016
51
CDMA Authentication
AKA-based Authentication
K (128-bit)
Provisioned in MS & AC.
RANDA (128-bit)
Received in AV and sent to MS.
SQN (48-bit)
Derived from CON_SQN, which is
part of AUTN received in AV and
sent to MS
f1
MS: XMAC_A
AC: MAC_A
(64-bit)
AMF (16-bit)
Part of AUTN received in AV and
sent to MS.
1
2
Figure 11-6: Generation of (X)MAC_A for AKA
3
6
The XMAC_A generated by the MS will only match the MAC_A received from the network if
the master key (K) provisioned in the home AC is the same as the one provisioned in the
MS. Therefore, by comparing XMAC_A with MAC_A, the MS can ensure that the AV being
used for this AKA was generated by its authentic home AC.
7
11.4.4 AKA rejection by the MS (i.e. MAC_A mismatch)
8
If the MAC_A received from the network in the AUTN does not match the XMAC_A value
generated by the MS, the MS will reject the authentication request as shown below.
4
5
9
Visited
System
Home
HLR/AC
auth request
RANDA, AUTN
auth reject
MS determines that the MAC_A contained in the AUTN
does not match the XMAC_A value generated based
on its master key and received RANDA & AUTH inputs
AKAREPORT
AKARPT
Failure report sent with an
AKARPT value of
“Reject”.
akareport
10
11
Figure 11-7: AKA rejection by the MS (i.e. MAC_A mismatch)
12
Upon receiving an authentication reject from the MS, the visited system sends an AKA
status report (AKAREPORT) to the home system with an AKARPT set to “Reject.” Beyond
acknowledging the AKAREPORT with a return response (akareport), no further action is
taken by the home system.
13
14
15
CDG #138, Rev 0.34
February 12, 2016
52
CDMA Authentication
1
AKA-based Authentication
11.5 Authentication of the MS by the network
5
Authentication of the MS by the network in AKA is similar to a unique challenge without
shared SSD in CAVE. In both cases, the home system generates both the random
challenge value that is sent to the MS and the response value that is expected from the MS.
In AKA these values are the RANDA and XRES, respectively.
6
11.5.1 Authentication response (RES)
7
The f2 algorithm with inputs shown below is used by the MS to generate the response (RES)
value and by the home AC to generate the XRES value.
2
3
4
8
K (128-bit)
Provisioned in MS & AC.
RANDA (128-bit)
f2
MS: RES
AC: XRES
(32-128 bit)
Received in AV and sent to MS.
9
10
Figure 11-8: Generation of (X)RES for AKA
11
13
If the RES value returned by the MS matches the XRES value contained in the AV being
used for the AKA attempt, the network is assured that the master key provisioned in the MS
matches the one provisioned in its home AC.
14
11.5.2 AKA authentication failure (i.e. RES mismatch)
15
If the RES and XRES values do not match, the MS fails authentication and the visited
system sends an AKA status report (AKAREPORT) to the home system with an AKARPT
value set to “Response Failure” as shown below.
12
16
17
CDG #138, Rev 0.34
February 12, 2016
53
CDMA Authentication
AKA-based Authentication
Visited
System
Home
HLR/AC
auth request
RANDA, AUTN
auth response
RES
AKAREPORT
AKARPT
RES from MS does not match XRES in
AV. Failure report sent with an
AKAPRT value of “Response Failure.”
akareport
AUTHDEN,
DENAUTHPER
Home system responds with AUTHDEN
set to “MS is not authorized” and the
interval required before re-authorization
specified in DENAUTHPER
1
2
Figure 11-9: AKA response failure (i.e. RES mismatch)
3
Upon receiving the AKAREPORT indicating response failure, the home system responds
with an authentication denied (AUTHDEN) parameter set to “MS is not authorized” and a
deny authentication period (DENAUTHPER) parameter set to the time interval that the
visited network should wait before attempting re-authorization with the MS.
4
5
6
7
CDG #138, Rev 0.34
February 12, 2016
54
CDMA Authentication
References
12. References
1
[1]
3GPP2 C.S0004-D (IS-2000.4-D); Signaling Link Access Control (LAC) Standard for
cdma2000 Spread Spectrum Systems; v1.0; February 2004
[2]
3GPP2 C.S0005-D (IS-2000.5-D); Upper Layer (Layer 3) Signaling Standard for
cdma2000 Spread Spectrum Systems; v1.0; February 2004
[3]
3GPP2 C.S0016-B (TIA-683-C); Over the Air Service Provisioning of Mobile Stations
in Spread Spectrum Systems; v1.0; March 2003
[4]
3GPP2 N.S0005-0 (TIA-41-D); Cellular Radiotelecommunications Intersystem
Operations; v1.0; December 1998
10
[5]
3GPP2 N.S0011-0 (IS-725-A); OTASP and OTAPA; January 1999
11
[6]
3GPP2 N.S0014-0 (IS-778); Authentication Enhancements; v1.0; January 1999
12
[7]
3GPP2 X.S0004-xxx-E (TIA-41-E); Wireless Radiotelecommunications Intersystem
Operations series of recommendations where xxx indicates document number:
2
3
4
5
6
7
8
9
13
14
000; Introduction to MAP; v3.0; October 2005
15
540; MAP Operations Signaling Protocols; v1.0.0; March 2004
16
550; MAP Parameters Signaling Protocols; v1.0.0; March 2004
17
640; Intersystem Procedures; v1.0; July, 2005
18
691; Annexes; v2.0; September 2005
19
20
[8]
3GPP2 X.S0006-0 (TIA-945); MAP Support of Authentication and Key Agreement
(AKA); v1.0; October 2005.
21
CDG #138, Rev 0.34
February 12, 2016
55
CDMA Authentication
Terminology
13. Terminology
1
AC
Authentication Center. Contains cryptographic information used in
validating the authenticity of mobile stations. The AC may be
contained within the HLR or a separate entity that communicates with
the HLR via TIA-41.
AKA
Authentication and Key Agreement. The 3rd generation authentication
mechanism intended to replace CAVE. AKA for CDMA architecture
was adapted from 3GPP2 UMTS AKA.
A-Key
Authentication Key. A 64-bit secret key used in CAVE authentication.
The A-key is associated with a mobile station (MS) and provisioned
only in the MS and its associated authentication center. The A-key is
never shared over the air or with a visited network.
AV
Authentication Vector. A set of data provided by an authentication
center to a visited network to allow the visited network to perform AKA
with a mobile station.
CAVE
Cellular Authentication and Voice Encryption. The 2nd generation
authentication mechanism currently in use by CDMA carriers.
CK
Cipher Key. A 128-bit key used in AKA to support data confidentiality
(i.e. encryption).
CSC
Customer Service Center. An entity where carrier representatives
receive calls from customers wishing to subscribe to new service or
request changes in existing service. The CSC interfaces with the
OTAF to perform network and MS related changes necessary to
complete service provisioning requests.
ESA
Enhanced subscriber authentication. The general name for CDMA 3rd
generation authentication. AKA was selected to implement ESA.
References to CDMA 3rd generation authentication typically use the
term AKA rather than ESA.
CDG #138, Rev 0.34
February 12, 2016
57
CDMA Authentication
Terminology
ESN
Electronic Serial Number. A unique number embedded in a wireless
phone unit by the manufacturer that is used to identify a mobile station
for billing and fraud control purposes. According to the Federal
Communications Commission, the ESN is to be fixed and
unchangeable, a unique fingerprint for each phone. The ESN is used in
conjunction with the MIN to create a unique identifier for a user.
HLR
Home Location Register. An SS7 entity with a database containing
information on the current location and validation status of a carrier’s
subscribers. To support roaming, the HLR communicates via TIA-41
with VLRs in visited networks. To support authentication, the HLR may
either communicate via TIA-41 with the authentication center or simply
incorporate authentication center functionality.
IK
Integrity key. 128-bit key used in AKA to support data integrity.
K
Master Key. 128-bit authentication key used in AKA. Comparable to
the A-key in CAVE, K is associated with a mobile station and
provisioned only in the MS and its associated authentication center. K
is never shared over the air or with a visited network.
IMSI
International Mobile Subscriber Identity. A string of decimal digits, up to
15 digits, that identifies a unique mobile terminal or mobile subscriber
internationally. The IMSI consists of three fields: the mobile country
code, the mobile network code, and a mobile subscriber identification
number.
IMSI_S
34-bit value that corresponds to the last 10 digits of the IMSI.
IMSI_S1
24-bit value that corresponds to the last 7 digits of the IMSI_S.
IS-2000
cdma2000 Standards for Spread Spectrum Systems series of
recommendations.
MIN
Mobile Identification Number. A 10-digit number assigned by the
carrier to a mobile station and used with the ESN to uniquely identify a
mobile station on the network. Unlike the ESN, the MIN is changeable.
MS
Mobile Station. Term used to describe the mobile phone.
MSIN
Mobile Station Identification Number. Nine- to eleven-digit part of the
IMSI that identifies an individual handset on a network within a country.
CDG #138, Rev 0.34
February 12, 2016
58
CDMA Authentication
Terminology
NAM
Number Assignment Module. A set of operational parameters that
include mobile directory number, access overload class, IMSI, and
SID/NID pair. NAM parameters are updated when activating a new
service or changing an existing one.
OTAF
Over-The-Air Function. An entity that interfaces with the CSC to
support service provisioning activities and the MSC to send MS orders
necessary to complete service provisioning requests. The OTAF is
often part of the HLR or MC.
OTAPA
Over-the-Air Parameter Administration. Over-the-air provisioning
initiated by the network.
OTASP
Over-the-Air Service Provisioning. Over-the-air provisioning initiated
by the user entering an activation code.
SSD
Secret Shared Data. 128-bit sub-key used in CAVE. The SSD is
comprised of two 64-bit keys: SSD_A and SSD_B. SSD may be
shared with a visited system to enable local authentication.
SSD_A
64-bit portion of the SSD used for creating authentication signatures.
SSD_B
64-bit portion of the SSD used for generating keys to encrypt voice and
signaling messages.
TIA-41
Wireless Radiotelecommunications Intersystem Operations series of
recommendations.
UAK
UIM Authentication Key. 128-bit key used in AKA to prevent a rogue
mobile station that uses subscription and security information obtained
from the R-UIM when the R-UIM is not present in the mobile station.
VLR
Visitor Location Register. The switch database containing information
on the current location and validation status of other carrier's
subscribers who are roaming in the carrier’s home market. The VLR
communicates via TIA-41 with the HLR’s in these roamers’ home
systems. The VLR is often incorporated in the MSC but may also a
separate entity communicating via TIA-41 with the MSC.
1
CDG #138, Rev 0.34
February 12, 2016
59
CDMA Authentication
1
TIA-41-D Authentication Reference
14. TIA-41-D Authentication Reference
2
14.1 TIA-41-D new relevant operations
3
14.1.1 AuthenticationDirective (AUTHDIR)
4
5
The AuthenticationDirective operation is used to request modification of an MS’s
authentication parameters.
Invoke Parameters
Return Result Parameters
ElectronicSerialNumber
MobileIdentificationNumber
AuthenticationAlgorithmVersion
AuthenticationResponseUniqueChallenge
CallHistoryCount
DenyAccess
LocationAreaID
RandomVariableSSD
RandomVariableUniqueChallenge
SenderIdentificationNumber
SharedSecretData
SSDNotShared
UpdateCount
M
M
M
O
O
O
O
O
O
O
O
O
O
CallHistoryCount
O
6
14.1.2 AuthenticationDirectiveForward (AUTHDIRFWD)
7
The AuthenticationDirectiveForward operation is sent from the Anchor MSC toward the
Serving MSC to request the initiation of a Unique Challenge to the indicated MS. This
message can be relayed through the Tandem MSC(s).
8
9
Invoke Parameters
Return Result Parameters
InterMSCCircuitID
MobileIdentificationNumber
AuthenticationResponseUniqueChallenge
RandomVariableUniqueChallenge
M
M
O
O
UniqueChallengeReport
M
10
14.1.3 AuthenticationFailureReport (AFREPORT)
11
The AuthenticationFailureReport operation is used to report on the failure of an
autonomously initiated authentication operation for an MS.
12
Invoke Parameters
ElectronicSerialNumber
MobileIdentificationNumber
ReportType
SystemAccessType
SystemCapabilities (Serving)
CallHistoryCount
CallHistoryCountExpected
MSCID (Serving MSC)
ReportType
SenderIdentificationNumber
CDG #138, Rev 0.34
Return Result Parameters
M
M
M
M
M
O
O
O
O
O
AuthenticationAlgorithmVersion
AuthenticationResponseUniqueChallenge
CallHistoryCount
DenyAccess
RandomVariableSSD
RandomVariableUniqueChallenge
SharedSecretData
SSDNotShared
TerminalType
UpdateCount
February 12, 2016
O
O
O
O
O
O
O
O
O
O
61
CDMA Authentication
TIA-41-D Authentication Reference
1
14.1.4 AuthenticationRequest (AUTHREQ)
2
Used to request authentication of an authentication-capable MS.
Invoke Parameters
Return Result Parameters
ElectronicSerialNumber
MobileIdentificationNumber
MSCID (Serving MSC)
SystemAccessType
SystemCapabilities (Serving)
AuthenticationData
AuthenticationResponse
CallHistoryCount
ConfidentialityModes (Actual)
Digits (Dialed)
PC_SSN (Serving MSC or VLR or HLR)
RandomVariable
SenderIdentificationNumber
TerminalType
M
M
M
M
M
O
O
O
O
O
O
O
O
O
AuthenticationAlgorithmVersion
AuthenticationResponseUniqueChallenge
CallHistoryCount
CDMAPrivateLongCodeMask
DenyAccess
RandomVariableSSD
RandomVariableUniqueChallenge
SharedSecretData
SignalingMessageEncryptionKey
SSDNotShared
UpdateCount
VoicePrivacyMask
O
O
O
O
O
O
O
O
O
O
O
O
3
14.1.5 AuthenticationStatusReport (ASREPORT)
4
Used to report on the outcome of an authentication operation initiated by the AC or VLR if
SSD is shared.
5
Invoke Parameters
Return Result Parameters
ElectronicSerialNumber
MobileIdentificationNumber
SystemCapabilities (Serving)
CountUpdateReport
SenderIdentificationNumber
SSDUpdateReport
UniqueChallengeReport
M
M
M
O
O
O
O
AuthenticationAlgorithmVersion
AuthenticationResponseUniqueChallenge
CallHistoryCount
DenyAccess
RandomVariableSSD
RandomVariableUniqueChallenge
SharedSecretData
SSDNotShared
UpdateCount
6
14.1.6 BaseStationChallenge (BSCHALL)
7
Used to request a response to a Base Station Challenge Order received from an MS.
Invoke Parameters
ElectronicSerialNumber
MobileIdentificationNumber
RandomVariableBaseStation
SenderIdentificationNumber
Return Result Parameters
M
M
M
O
AuthenticationResponseBaseStation
8
14.1.7 CountRequest (COUNTREQ)
9
Used to obtain the current value of the COUNT parameter.
Invoke Parameters
ElectronicSerialNumber
MobileIdentificationNumber
SenderIdentificationNumber
CDG #138, Rev 0.34
O
O
O
O
O
O
O
O
O
M
Return Result Parameters
M
M
O
CallHistoryCount
February 12, 2016
M
62
CDMA Authentication
TIA-41-D Authentication Reference
1
14.1.8 RandomVariableRequest (RANDREQ)
2
The RandomVariableRequest operation is used by the Serving MSC to request the value of
RAND from a Border MSC corresponding to the RANDC received from an MS. This
operation may be used if the value of RANDC received from an MS corresponds to a RAND
value that may be transmitted by a Border MSC which is transmitting the same SID as the
Serving MSC.
3
4
5
6
Invoke Parameters
Return Result Parameters
MSCID (Serving MSC)
RANDC
ServingCellID
M
M
M
RandomVariable
RANDValidTime
O
O
7
14.2 TIA-41-D new relevant parameters
8
14.2.1 AuthenticationAlgorithmVersion (AAV)
9
11
May be sent with messages that also contain the SSD parameter to indicate the version (0
through 255) of CAVE algorithm that was used to calculate the SSD. If this parameter is not
received, the default value of 199 is used.
12
14.2.2 AuthenticationCapability (AUTHCAP)
13
Sent from the HLR to the serving MSC to indicate whether or not authentication is required
for the mobile.
10
14
Authentication Capability
No authentication required.
Authentication required.
15
14.2.3 AuthenticationData (AUTHDATA)
16
17
Contains the 24-bit authentication data used as input to CAVE for call origination.
AUTHDATA is derived from the information sent by the MS (e.g. last six dialed digits).
18
14.2.4 AuthenticationResponse (AUTHR)
19
21
Contains the 18-bit authentication response generated by an MS when accessing the
system (e.g., call origination, page response or autonomous registration). It is computed by
CAVE using the SSD of the MS and the RAND chosen by the visited MSC.
22
14.2.5 AuthenticationResponseBaseStation (AUTHBS)
23
24
Contains the 18-bit response to a Base Station Challenge Order, computed by CAVE using
the new SSD of the MS and the RANDBS chosen by the MS.
25
14.2.6 AuthenticationResponseUniqueChallenge (AUTHU)
20
26
27
Contains the MS’s 18-bit response to a Unique Challenge Order, computed by CAVE using
the SSD of the MS and the RANDU.
CDG #138, Rev 0.34
February 12, 2016
63
CDMA Authentication
TIA-41-D Authentication Reference
1
14.2.7 CallHistoryCount (COUNT)
2
7
Contains a 6-bit, modulo 64 (i.e. increments from 0 to 63 and wraps back around to 0), event
counter used for clone detection. It is maintained by the MS and AC (and serving VLR if
shared with the serving system). The events that result in incrementing the counter are
defined by local administrative procedures at the AC (and at the VLR if shared with the
serving system) and may include initial registration in a new serving MSC, call origination,
page response, or periodically.
8
14.2.8 CallHistoryCountExpected (COUNTEx)
9
10
Contains a modulo 64 event counter which was expected from the MS. The value received
from the MS is sent in the COUNT parameter.
11
14.2.9 CountUpdateReport (COUNTRPT)
12
Indicates the outcome of the COUNT Update initiated by the AC or the VLR using.
3
4
5
6
COUNT Update Report
COUNT Update not attempted.
COUNT Update no response.
COUNT Update successful.
13
14.2.10 DenyAccess (DENACC)
14
Sent by the home AC to indicate that MS is invalid. This parameter includes a field to
indicate why the access is being denied as shown below:
15
DenyAccess Reason
Unspecified.
SSD Update failure.
COUNT Update failure.
Unique Challenge failure.
AUTHR mismatch.
COUNT mismatch.
Process collision.
Missing authentication parameters.
TerminalType mismatch.
MIN or ESN authorization failure.
16
14.2.11 RANDC
17
19
Indicates which Random Variable was used by an MS to compute AUTHR. Values of the
RANDC may be coordinated between systems so that the RANDC also indicates which
MSC generated the random number variable.
20
14.2.12 RandomVariable (RAND)
21
Contains a 32-bit random number that is used as input to the CAVE algorithm for MS
authentication, Signaling Message Encryption, and digital channel Voice Privacy. The
random number is chosen by the Serving MSC.
18
22
23
CDG #138, Rev 0.34
February 12, 2016
64
CDMA Authentication
TIA-41-D Authentication Reference
1
14.2.13 RandomVariableBaseStation (RANDBS)
2
4
Contains a 32-bit random number that is used as input to the CAVE authentication algorithm
for base station authentication. The random number is chosen independently by the MS
during the process to update its SSD.
5
14.2.14 RandomVariableSSD (RANDSSD)
6
8
Contains a 56-bit random number that is used as input to the CAVE algorithm for generating
Shared Secret Data (SSD-A and SSD-B). The random number is chosen independently by
the AC during the process to update the MS’s SSD.
9
14.2.15 RandomVariableUniqueChallenge (RANDU)
3
7
13
Contains a 24-bit random number that is used as input to the CAVE algorithm for
authenticating a specific MS. The random number is chosen independently by the AC or
VLR whenever a unique challenge is prescribed by local AC or VLR authentication
procedures.
14
14.2.16 RANDValidTime (RANDVT)
15
Used to specify the period in minutes for which a received RAND is valid.
16
14.2.17 ReportType (RPTTYP)
17
Indicates the type of authentication failure being reported by the Visited System (MSC or
VLR) to the AC.
10
11
12
18
Report Type
Unspecified security violation.
MIN/ESN mismatch.
RANDC mismatch.
SSD Update failed.
COUNT mismatch.
Unique Challenge failed.
Unsolicited Base Station Challenge.
SSD Update no response.
COUNT Update no response.
Unique Challenge no response.
AUTHR mismatch.
TERMTYP mismatch.
Missing authentication parameters.
19
14.2.18 SharedSecretData (SSD)
20
Contains the 64-bit SharedSecretData-A (SSD-A) used in authentication of an MS and 64-bit
SharedSecretData-B (SSD-B) used as a cryptovariable in Voice Privacy and Signaling
Message Encryption for an MS. SSD is computed only at the AC and at the MS since it is
based on the secret subscriber A-Key shared only between the AC and MS.
21
22
23
CDG #138, Rev 0.34
February 12, 2016
65
CDMA Authentication
TIA-41-D Authentication Reference
1
14.2.19 SSDNotShared (NOSSD)
2
3
Used by the home system to indicate that the previously provided SSD is no longer valid and
should be discarded.
4
14.2.20 SSDUpdateReport (SSDURPT)
5
Indicates the outcome of the SSD Update initiated by the AC using one of the following
values: not attempted, no response, successful, or failed.
6
SSD Update Report
SSD Update not attempted.
SSD Update no response.
SSD Update successful.
SSD Update failed.
7
14.2.21 SystemCapabilities (SYSCAP)
8
Sent from the serving MSC to the home AC to indicate the authentication, encryption, and
voice privacy capabilities of the serving system.
9
Field Name
Values
AUTH
Auth parameters were not requested on this system access (AUTH=0 in the OMT).
Auth parameters were requested on this system access (AUTH=1 in the OMT).
Signaling message encryption not supported by the system.
Signaling message encryption supported by the system.
Voice privacy not supported by the system.
Voice privacy supported by the system.
System cannot execute CAVE algorithm and cannot share SSD for the indicated MS.
System can execute CAVE algorithm and share SSD for the indicated MS.
SSD is not shared with the system for the indicated MS.
SSD is shared with the system for the indicated MS.
SE
VP
CAVE
SSD
10
14.2.22 UniqueChallengeReport (UCHALRPT)
11
12
Indicates the outcome of the Unique Challenge initiated by the AC or the VLR using one of
the following values: not attempted, no response, successful, or failed.
13
14.2.23 UpdateCount (UPDCOUNT)
14
Used to initiate the CallHistoryCount (COUNT) update procedure.
CDG #138, Rev 0.34
February 12, 2016
66
CDMA Authentication
1
2
3
4
5
6
7
8
9
10
11
12
13
TIA-41-E Authentication Reference
15. TIA-41-E Authentication Reference
15.1 TIA-41-E updates to existing relevant operations
Parameters that have been added to an operation in release E are shown in red and
followed by an asterisk (*). Note that these parameters may not be new to release E, simply
new to the operation as defined in release D; for example, because release E supports the
RoutingDigits parameter in the AUTHREQ Return Result (authreq) operation, this parameter
is shown as RoutingDigits*. While RoutingDigits is not new to release E, support for it in this
operation is new. Likewise, parameters that have been removed from an operation in
release E are shown in strikethrough grey.
15.1.1 AuthenticationDirective (AUTHDIR)
The AuthenticationDirective operation is used to request modification of an MS’s
authentication parameters. It is also used to transport encryption parameters to the Serving
MSC for CDMA OTASP, TDMA OTASP and CDMA OTAPA.
Invoke Parameters
Return Result Parameters
Unchanged, existing parms not shown
MobileIdentificationNumber MSID*
AuthenticationAlgorithmVersion
AuthenticationResponseReauthentication*
CarrierDigits*
CaveKey*
CDMAPrivateLongCodeMask*
DestinationDigits*
MobileStationMIN*
MSCID*
RandomVariableReauthentication*
RoutingDigits*
ServiceIndicator*
SignalingMessageEncryptionKey*
VoicePrivacyMask*
…
M
MO
O
O
O
O
O
O
O
O
O
O
O
O
Unchanged, existing parms not shown
…
14
15.1.2 AuthenticationDirectiveForward (AUTHDIRFWD)
15
The AuthenticationDirectiveForward operation is sent from the Anchor MSC toward the
Serving MSC to request initiation of one or more authentication processes for the indicated
MS. This operation can be relayed through the Tandem MSC(s).
16
17
Invoke Parameters
Unchanged, existing parms not shown
MobileIdentificationNumber
UpdateCount*
IMSI*
CDG #138, Rev 0.34
Return Result Parameters
…
MO
O
O
Unchanged, existing parms not shown
UniqueChallengeReport
CountUpdateReport*
February 12, 2016
…
MO
O
67
CDMA Authentication
TIA-41-E Authentication Reference
1
15.1.3 AuthenticationFailureReport (AFREPORT)
2
The AuthenticationFailureReport operation is used to report on the failure of an
autonomously initiated authentication operation for an MS.
3
Invoke Parameters
Return Result Parameters
…
M
O
O
Unchanged, existing parms not shown
MobileIdentificationNumber MSID*
ReportType
TerminalType*
Unchanged, existing parms not shown
CarrierDigits*
DestinationDigits*
MobileIdentificationNumber*
RoutingDigits*
4
15.1.4 AuthenticationRequest (AUTHREQ)
5
Used to request authentication of an authentication-capable MS.
Invoke Parameters
…
O
O
O
O
Return Result Parameters
Unchanged, existing parms not shown
MobileIdentificationNumber MSID*
CDMANetworkIdentification* (Serving MSC)
ControlChannelMode*
ServiceRedirectionCause*
SuspiciousAccess*
TransactionCapability*
…
M
O
O
O
O
O
Unchanged, existing parms not shown
AnalogRedirectRecord*
CarrierDigits*
CaveKey*
CDMARedirectRecord*
DataKey*
DestinationDigits*
MobileIdentificationNumber*
RoamingIndication*
RoutingDigits*
ServiceRedirectionInfo*
…
O
O
O
O
O
O
O
O
O
O
6
15.1.5 AuthenticationStatusReport (ASREPORT)
7
Used to report on the outcome of an authentication operation initiated by the AC or VLR if
SSD is shared.
8
Invoke Parameters
Return Result Parameters
…
M
O
O
O
O
O
O
Unchanged, existing parms not shown
MobileIdentificationNumber MSID*
EnhancedPrivacyEncryptionReport*
MSCID* (Serving)
ReauthenticationReport*
ServiceIndicator*
SignalingMessageEncryptionReport*
VoicePrivacyReport*
9
10
Unchanged, existing parms not shown
CarrierDigits*
DestinationDigits*
MobileIdentificationNumber*
RoutingDigits*
…
O
O
O
O
15.1.6 BaseStationChallenge (BSCHALL)
Used to request a response to a Base Station Challenge Order received from an MS.
Invoke Parameters
Unchanged, existing parms not shown
MobileIdentificationNumber MSID*
ServiceIndicator*
CDG #138, Rev 0.34
Return Result Parameters
…
M
O
Unchanged, existing parms not shown
February 12, 2016
…
68
CDMA Authentication
TIA-41-E Authentication Reference
1
15.1.7 CountRequest (COUNTREQ)
2
Used to obtain the current value of the COUNT parameter.
Invoke Parameters
Unchanged, existing parms not shown
MobileIdentificationNumber MSID*
Return Result Parameters
…
M
Unchanged, existing parms not shown
…
3
15.1.8 RandomVariableRequest (RANDREQ)
4
Used by the Serving MSC to request the value of RAND from a Border MSC corresponding
to the RANDC received from an MS. This operation may be used if the value of RANDC
received from an MS corresponds to a RAND value that may be transmitted by a Border
MSC which is transmitting the same SID as the Serving MSC.
5
6
7
Invoke Parameters
Unchanged, existing parms not shown
Return Result Parameters
…
Unchanged, existing parms not shown
RandomVariable
RANDValidTime
…
OM
OM
8
15.1.9 SMSDeliveryPointToPoint (SMDPP)
9
General purpose operation used to convey a short message or in general any other
information or encapsulated data from one point to another point and report on the success
or failure of that transfer (for example, as used in SMS and CDMA OTASP).
10
11
Invoke Parameters
Unchanged, existing parms not shown
ActionCode*
MobileIdentificationNumber MSID*
NewlyAssignedMIN*
NewlyAssignedIMSI*
ServiceIndicator*
TemporaryReferenceNumber*
Return Result Parameters
…
O
M
O
O
O
O
Unchanged, existing parms not shown
AuthorizationDenied*
DenyAccess*
ElectronicSerialNumber*
MobileStationMIN MobileStationMSID*
MSCID*
SystemCapabilities*
…
O
O
O
O
O
O
12
15.2 TIA-41-E new relevant operations
13
15.2.1 OTASPRequest (OTASPREQ)
14
Used by the OTAF to request the initiation of certain AC procedures (such as A-key
Generation, SSD Update, and Commit/Release of a temporary A-key, etc.), and to also
return certain parameters.
15
16
Invoke Parameters
ActionCode
AKeyProtocolVersion
AuthenticationData
AuthenticationResponse
CallHistoryCount
ElectronicSerialNumber
MSID
MobileStationMSID
MobileStationPartialKey
CDG #138, Rev 0.34
O
O
O
O
O
O
O
O
O
Return Result Parameters
AKeyProtocolVersion
AuthenticationResponseBaseStation
BaseStationPartialKey
DenyAccess
EnhancedPrivacyEncryptionReport
ModulusValue
OTASP_ResultCode
PrimitiveValue
SignalingMessageEncryptionReport
February 12, 2016
O
O
O
O
O
O
O
O
O
69
CDMA Authentication
TIA-41-E Authentication Reference
MSCID (Serving MSC)
NewlyAssignedMSID
PC_SSN
RandomVariable
RandomVariableBaseStation
ServiceIndicator
SystemCapabilities
TerminalType
O
O
O
O
O
O
O
O
SSDUpdateReport
UniqueChallengeReport
VoicePrivacyReport
O
O
O
1
15.3 TIA-41-E updates to existing relevant parameters
2
15.3.1 ActionCode (ACTCODE)
3
Specifies the nature of the action to be performed by the designated functional entity. New
fields added.
4
Values
Existing values not shown…
Attach MSC to OTAF.
Initiate RegistrationNotification.
Generate Public Encryption values.
Generate A-key.
Perform SSD Update procedure.
Perform re-authentication procedure.
Release TRN.
Commit A-key.
Release Resources (e.g., A-key, Traffic Channel).
Record NEWMSID.
Allocate Resources (e.g., Multiple message traffic channel delivery).
Generate Authentication Signature.
5
6
15.3.2 SystemCapabilities (SYSCAP)
7
New fields added.
Field Name
Values
…
DP*
Existing fields not shown…
Data privacy is not supported by the system.
Data privacy is supported by the system.
TDMA enhanced privacy and encryption is not supported by the system.
TDMA enhanced privacy and encryption is supported by the system.
T-EPE*
CDG #138, Rev 0.34
February 12, 2016
70
CDMA Authentication
TIA-41-E Authentication Reference
1
15.4 TIA-41-E new relevant parameters
2
15.4.1 AKeyProtocolVersion (AKEYPV)
3
Used to send A-Key Generation Procedure protocol version(s) supported by the MS or
selected by the AC.
4
A-Key Generation Procedure Protocol Version
A-Key Generation not supported.
Diffie Hellman with 768-bit modulus, 160-bit primitive, and 160-bit exponents.
Diffie Hellman with 512-bit modulus, 160-bit primitive, and 160-bit exponents.
Diffie Hellman with 768-bit modulus, 32-bit primitive, and 160-bit exponents.
5
15.4.2 AuthenticationResponseReauthentication (AUTHRA)
6
8
Contains the 18-bit authentication response generated by an MS for reauthentication. It is
computed by the Auth_Signature procedure using the SSD of the MS and a RANDRA
chosen by the AC.
9
15.4.3 BaseStationPartialKey (BSKEY)
7
10
Used to send the Base Station partial key value for the A-Key Generation procedure.
11
15.4.4 MobileStationPartialKey (MSKEY)
12
Used to send the MS partial key value for the A-Key Generation procedure.
13
15.4.5 OTASP_ResultCode (OTASPRC)
14
Used to specify the result of an OTASP related AC procedure.
Result Code
Accepted.
Rejected.
Computation Failure – e.g. unable to compute A-key.
CSC Rejected – CSC challenge failure.
Unrecognized OTASPCallEntry.
Unsupported AKeyProtocolVersion(s).
Unable to Commit.
15
15.4.6 RandomVariableReauthentication (RANDRA)
16
17
Contains the 32-bit random number that is used as input to the Auth_Signature algorithm for
MS Reauthentication. The random number is chosen by the AC.
18
15.4.7 ReauthenticationReport (RARPT)
19
Indicates the outcome of the Reauthentication procedure initiated by the AC.
Reauthentication Report
Reauthentication not attempted.
Reauthentication no response.
CDG #138, Rev 0.34
February 12, 2016
71
CDMA Authentication
TIA-41-E Authentication Reference
Reauthentication successful.
Reauthentication failed.
1
15.4.8 SuspiciousAccess (SUSACC)
2
Indicates the received dialed digits are anomalous or that an access is possibly fraudulent.
Suspicious Access
Anomalous Digits (the dialed digits may contain extraneous digits).
Unspecified (access regarded as suspicious for a reason other than receipt of
extraneous dialed digits).
CDG #138, Rev 0.34
February 12, 2016
72
CDMA Authentication
1
TIA-945 Authentication Reference
16. TIA-945 Authentication Reference
3
TIA-945 builds upon TIA-41-E recommendations to introduce MAP support of Authentication
and Key Agreement (AKA).
4
16.1 TIA-945 updates to existing authentication operations
5
16.1.1 AuthenticationRequest (AUTHREQ)
6
Parameters added.
2
Invoke Parameters
Existing parameters not shown…
AKA_VectorCount*
Return Result Parameters
…
O
7
16.1.2 RegistrationNotification (REGNOT)
8
Parameter added.
Invoke Parameters
Existing parameters not shown…
AKA_Report*
9
Existing parameters not shown…
AKA_AuthenticationVector*
AKA_AuthenticationVectorList*
…
O
O
Return Result Parameters
…
O
Existing parameters not shown…
…
16.2 TIA-945 new authentication operations
10
16.2.1 AKADirective (AKADIR)
11
Used to establish a new security association or revoke the MS’s current security association.
Invoke Parameters
MSID
AKA_AuthenticationVector
Return Result Parameters
M
O
12
16.2.2 AKARequest (AKAREQ)
13
Used to request new authentication vectors when the ability of the MS, the serving system,
and the home system to perform AKA has been established.
14
Invoke Parameters
MSID
MSCID (Serving MSC)
SystemAccessType
SystemCapabilities (Serving)
AKA_VectorCount
AUTS
RANDA
CDG #138, Rev 0.34
Return Result Parameters
M
M
M
M
O
O
O
AKA_AuthenticationVector
AKA_AuthenticationVectorList
AuthorizationDenied
DeniedAuthorizationPeriod
February 12, 2016
O
O
O
O
73
CDMA Authentication
TIA-945 Authentication Reference
1
16.2.3 AKAStatusReport (AKAREPORT)
2
Used to report on the outcome of an authentication operation initiated by the HLR or VLR.
Invoke Parameters
Return Result Parameters
MSID
MSCID (Serving MSC)
SystemCapabilities (Serving)
AKA_Report
AKA_VectorCount
AUTS
RANDA
M
M
M
M
O
O
O
AKA_AuthenticationVector
AKA_AuthenticationVectorList
AuthorizationDenied
DeniedAuthorizationPeriod
3
16.3 TIA-945 updates to existing authentication parameters
4
16.3.1 AuthenticationCapability (AUTHCAP)
5
Values expanded to distinguish between CAVE and AKA authentication.
O
O
O
O
Authentication Capability
No authentication required.
Authentication required. CAVE authentication required*
AKA authentication required. CAVE not supported for MS*
Authentication required. CAVE or AKA authentication supported for MS*
6
16.3.2 SystemCapabilities (SYSCAP)
7
AKA field added.
Field Name
Values
…
AKA*
Existing fields not shown…
AKA is not supported*
AKA is supported by the system*
8
16.4 IS-945 new authentication parameters
9
16.4.1 AKA_AuthenticationVector (AKAV)
10
Includes information required for one AKA authentication.
AKA_AuthenticationVector Fields
Cipher key (CK).
Integrity key (IK).
Random value (RANDA).
Concealed sequence number (CON_SQN).
Authentication management field (AMF).
Message authentication code (MAC_A)
Expected authentication response (XRES)
UIM authentication key (UAK) - optional
CDG #138, Rev 0.34
February 12, 2016
74
CDMA Authentication
TIA-945 Authentication Reference
1
16.4.2 AKA_AuthenticationVectorList (AKAVL)
2
Used to specify one or more AKA authentication vectors.
3
16.4.3 AKA_Keys (AKAK)
4
Includes keys that may need to be passed between MSCs for some inter-system operations.
AKA_Keys Fields
Cipher key (CK).
Integrity key (IK).
UIM authentication key (UAK) - optional
5
16.4.4 AKA_Report
6
Used to report on the outcome of an AKA authentication operation.
Field Name
Values
AKA code
Success. The AKA operation was successful.
Response Failure. A RES/XRES mismatch has been detected.
Reject. The MS sent an authentication reject to the serving MSC.
Loss of Radio Contact. The serving MSC lost radio contact with the
MS being authenticated.
REPF
No repeated failure . A new authentication failure has been detected.
Repeated failure. A repeated failure has occurred.
7
16.4.5 AKA_VectorCount
8
Used to request a number of AKA authentication vectors from the AC. The AC may return
fewer than this, but not more.
9
10
16.4.6 AUTS
11
AKA authentication token for resynchronization.
AUTS Fields
Concealed MS sequence number (CON_MS_SQN).
Message authentication code for resynchronization (MAC_S).
12
16.4.7 RANDA
13
Contains the 128-bit random challenge number used in an AKA authentication vector.
14
CDG #138, Rev 0.34
February 12, 2016
75