Docstoc

CDMA Authentication

Document Sample
CDMA Authentication Powered By Docstoc
					        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                                              November 8, 2011                                                                         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                                            November 8, 2011                                                                         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                                             November 8, 2011                                                                        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                                         November 8, 2011                                                                      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                                          November 8, 2011                                                                        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 ........................................................................................ 38
      Figure 9-4: OTAF-initiated SSD update procedure .................................................................... 39
      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                                         November 8, 2011                                                                   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                                       November 8, 2011                                                                vii
CDMA Authentication                                                                                   Introduction




 1                                                                     1. Introduction

 2   This paper specifically focuses on the security concept of authentication. While written from
 3   the perspective of roaming, the authentication information presented herein should be useful
 4   for any carrier interested in implementing or updating authentication support.

            nd
 5   Both 2 generation authentication based on Cellular Authentication and Voice Encryption
                     rd
 6   (CAVE) and 3 generation authentication based on Authentication and Key Agreement
 7   (AKA) are addressed in this paper. In the context of CAVE, the term authentication refers to
 8   primarily unilateral1 mechanisms that allow the network to validate the authenticity of the
 9   roaming mobile station (MS). In the context of AKA, these mechanisms are bilateral and
10   support both network validation of MS authenticity and MS validation of network authenticity.
11   Additional security concepts such as encryption, data integrity, and security associations
12   may be mentioned but are considered to be outside the scope of this paper.

13   While this paper addresses both CAVE- and AKA-based authentication, the larger focus is
14   on CAVE. The reasoning for this choice of focus is to provide carriers with information,
15   insight, and recommendations on the authentication mechanisms currently being deployed.
16   CAVE continues to be deployed and will likely continue to be the most prevalent form of
17   authentication for the next several years while the industry migrates to AKA. During this
18   migration, interoperability will necessitate that AKA deployment be done in conjunction with
19   support for CAVE rather than as a complete replacement.

20   The discussion of CAVE-based authentication begins with an overview of authentication
21   issues and concepts, an introduction to A-key considerations, and an explanation of the
22   mechanisms employed by CAVE as defined in TIA-41-D. Following this, TIA-41-E
23   authentication enhancements and Over-The-Air (OTA) support are discussed. Finally,
24   practical recommendations are provided.

25   Information on CAVE is followed by an exploration of AKA-based authentication. AKA
26   concepts and details are presented in sufficient detail to allow carriers unfamiliar with AKA to
27   thoroughly understand AKA authentication mechanisms.

28   As may or may not be apparent, this progression of information maps roughly to the
29   evolution of CDMA authentication beginning with the introduction of network support for
30   CAVE-based authentication in TSB51 to the introduction of network support for AKA in TIA-
31   945. 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                               November 8, 2011                                               1
CDMA Authentication                                                                          Introduction




 1                            1-1: Evolution of CDMA authentication

         Release        Document     Description
         Dec. 1991      IS-41-B      Intersystem operations (no authentication support)

         May 1993       TSB51        CAVE-based authentication

         Feb. 1996      IS-41-C      Intersystem operations with TSB51-based
                                     authentication incorporated
         Jun. 1997      IS-725       OTASP capabilities including support for over-the-air
                                     A-key provisioning
         Dec. 1997      TIA-41-D     Essentially the same as IS-41-C
         Jan. 1999      IS-778       Enhancements to TIA-41-D authentication

         Jan. 1999      IS-725-A     Adds OTAPA capabilities as well as OTASP
         2004 – 2005    TIA-41-E     Intersystem operations with IS-725-A and IS-778
                                     incorporated
         Oct. 2005      TIA-945      MAP support of Authentication and Key Agreement
                                     (AKA) alternative to CAVE-based authentication
 2



 3   Reference sections containing various authentication operations, parameters, and fields
 4   discussed throughout the paper are provided at the end of the paper. These sections are
 5   separated into TIA-41-D, TIA-41-E, and TIA-945. References and modifications to existing
 6   items are highlighted to allow the reader to understand when various items were introduced
 7   and modified. These sections are not intended as a proxy to the standards documents for
 8   the purposes of implementation. Rather, the inclusion of these sections is an attempt to
 9   reduce reader frustration as often times being able to quickly reference additional
10   information such as which field values are supported by a particular parameter can clarify
11   uncertainty regarding its use or purpose.

12




CDG #138, Rev 0.34                          November 8, 2011                                           2
CDMA Authentication                                                                      Authentication Overview




 1                                            2. Authentication Overview
 2   2.1 What is cloning fraud
 3   A cloned mobile station or “clone” is simply a Mobile Station (MS) that has been
 4   programmed with illegally obtained Equipment Serial Number (ESN) and Mobile Station
 5   Identity (MSID) information. Because these ESN and MSID values are sent unencrypted
 6   over the air interface by the MS to identify itself to the network, it is possible for a fraudster to
 7   intercept them. However, it may also be possible for fraudsters to obtain these values from
 8   the MS if they are able to access programming mode or work with employees of a carrier to
 9   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
13   programmed into other mobile stations to create clones. The use of clones to fraudulently
14   access a carrier network is known as cloning fraud and is the most prevalent form of
15   technical fraud in CDMA networks.
16   While this may seem very complex for the average criminal to attempt, tools to assist in the
17   creation of clones are only an Internet search away. For example, for a few hundreds
18   dollars, a fraudster can readily purchase software and universal handset programming
19   equipment that allows them to reprogram a mobile station with new values for ESN, MSID,
20   A-key, etc… In the past, such equipment was only available to carriers for troubleshooting
21   purposes and cost thousands of dollars.


22   2.2 Why is authentication important
23   Cloning fraud has several costs. First, carriers incur lost revenue potential in the form of not
24   being compensated for fraudulent use. Next, customer care resources must be expended to
25   work with legitimate subscribers that have been cloned in order to resolve billing issues and
26   reprogram mobile stations. Finally, potential switching and intangible costs are associated
27   with lower customer satisfaction when these legitimate subscribers discover fraudulent
28   charges on their bills. In short, the result of cloning fraud is that carrier’s lose money and
29   legitimate subscribers are unhappy.
30   When a mobile station is cloned and used to fraudulently access the network of a roaming
31   partner, this situation is exacerbated. In the roaming scenario, not only does the home



CDG #138, Rev 0.34                               November 8, 2011                                             3
CDMA Authentication                                                               Authentication Overview




 1   network incur the aforementioned costs, but it must also pay the roaming partner for the
 2   intercarrier roaming charges resulting from the fraudulent access. This translates into real
 3   monetary costs that directly affect the home network’s bottom line.
 4   Authentication protects carrier networks from fraudulent access by cloned mobile stations.
 5   The mechanisms used by CAVE-based authentication ensure that a mobile station possess
 6   valid shared secret data before allowing it to access the network. These mechanisms
 7   protect both carriers and legitimate subscribers from the negative effects of cloning fraud.


 8   2.3 How effective is authentication
 9   The following subsections discuss the effectiveness of authentication in various technical
10   fraud scenarios. However, it should be noted that how effective an authentication
11   implementation is depends largely on policy decisions made by the home and visited
12   network. These policy decisions can make the difference between an effective and a
13   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   CAVE-based authentication is completely effective against regular cloning fraud. Any
21   attempt by a regular clone to access a network using authentication should be unsuccessful.
22   The reason is that, while the regular clone can identify itself as another subscriber using
23   illegally obtained ESN and MSID information, it will not possess valid shared secret data
24   required to successfully pass an authentication challenge. Therefore, authentication will
25   completely solve the majority of cloning fraud.

26   2.3.2 Complete clones

27   A less likely but more problematic scenario is the existence of a “complete clone.” A
28   complete clone is one that contains a correct A-key. Complete clones are more problematic
29   because they are able to successful complete SSD update procedures and authentication
30   challenges.
31   The existence of a complete clone indicates a problem with a carrier’s security procedures
32   that has allowed A-key information to be compromised. Nonetheless, as will be discussed
33   later in this paper, CAVE-based authentication provides a Call History Count (COUNT)
34   mechanism to help identify the existence of clones, even in the case of a complete clone.
35   Once identified, service may be denied, though this action will require the legitimate
36   subscriber to contact customer care to re-activate their service.




CDG #138, Rev 0.34                            November 8, 2011                                         4
CDMA Authentication                                                                    Authentication Overview




 1   2.3.3 Replay attacks

 2   A replay attack is a special scenario in which a fraudster intercepts the entire contents of a
 3   legitimate roamer’s message and “replays” this information from a clone. Because the
 4   intercepted message contained a correct global challenge response required to successfully
 5   complete authentication, the replayed message will also successfully complete
 6   authentication if the challenge value is the same. Therefore, replay attacks are inherently
 7   limited by how frequently the visited network changes the global challenge value sent to all
 8   mobile stations attempting to access the network.


 9   2.4 Authentication concepts
10   2.4.1 Cellular Authentication and Voice Encryption (CAVE)

11   Cellular Authentication and Voice Encryption (CAVE) is a set of cryptographic2 algorithms
12   collectively referred to as the CAVE algorithm which are used during the authentication
13   process. Based on the inputs used, the CAVE algorithm enables calculation of SSD during
14   the SSD Update procedure and authentication signatures during challenge/response
15   procedures. The CAVE algorithm is also used to calculate various values used during
16   optional encryption and voice privacy procedures which are not discussed in this document.
17   The CAVE algorithm used in CDMA is standardized and procedures are defined to ensure
18   that both the network and the MS are using the same version of CAVE algorithm during
19   authentication. If the MS is equipped with a removable user identity module (R-UIM), the
20   CAVE algorithm will reside on this R-UIM and all authentication calculations using the CAVE
21   algorithm will be performed by the R-UIM. Otherwise, the MS will perform these
22   calculations.

23   2.4.2 Authentication Key (A-key)

24   Also known as the “master key”, the A-key is the cornerstone of CAVE-based authentication.
25   The A-key is provisioned in the home Authentication Center (AC) and the mobile station
26   (MS). If the MS uses an R-UIM, the A-key is stored on this R-UIM; otherwise, the A-key is
27   stored in semi-permanent memory on the MS. In either case, users should not be able to
28   access or view the A-key on their MS. Once provisioned, an A-key is generally only
29   changed if the home operator suspects that it has been compromised.
30   The purpose of the A-key in authentication is to generate Shared Secret Data (SSD),
31   specifically an SSD_A secondary key. It is this SSD, not the A-key, that is used during the
32   authentication process. This helps protect the A-key from being compromised. While SSD
33   may be shared with a partner network to enable local authentication, the A-key, once
34   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                               November 8, 2011                                           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
 3   with the A-key as an input. This calculation occurs during a procedure called SSD Update.
 4   During the SSD Update procedure, both the Authentication Center (AC) and the Mobile
 5   Station (MS) separately calculate SSD. It is this SSD, not the A-key that is used during
 6   authentication.
 7   Note that the term “Shared Secret Data” refers to the fact that the secret data is shared
 8   between the network and the MS. This SSD may or may not also be shared between home
 9   and roaming partner networks. If the home network chooses not to share SSD with their
10   roaming partner network, it is still shared between home network and MS. If the home
11   network does share SSD with their roaming partner network, it is referred to as “Shared
12   SSD” because the SSD shared between home network and MS is also shared with the
13   partner network.
14   As shown below, the 128-bit SSD actually consists of two 64-bit keys: SSD_A and SSD_B.
15   The SSD_A key is the one used during authentication to calculate authentication signatures.
16   When authentication documents refer to SSD during the authentication process, they are
17   generally referring to SSD_A. The SSD_B key is not detailed in this document as its
18   purpose is to enable the generation of session keys that are used during optional encryption
19   and voice privacy procedures.




CDG #138, Rev 0.34                           November 8, 2011                                          6
CDMA Authentication                                                                              Authentication Overview




                                                      64-bit

                                              A-Key

                            ESN                                RAND_SSD




                                       CAVE algorithm




                                                                                SSD is a 128-bit value
                                     64-bit                            64-bit   that actually consists
                                                                                  of two 64-bit keys:
                            SSD_A                              SSD_B             SSD_A and SSD_B



                                                       SSD_B is used to
                       SSD_A is used during
                                                       generate session
                         authentication to
                                                       keys that enable
                        generate response
                                                       voice privacy and
                            signatures
                                                           encryption
 1



 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
 4   being compromised since SSD may be shared with a roaming partner network but the A-key
 5   is never shared. In addition, sharing SSD allows partner networks to locally perform
 6   authentication rather than requiring all partner networks to proxy authentication signaling
 7   back to the home HLR/AC. As a home network scales its roaming business with additional
 8   partner networks, sharing of SSD becomes increasingly important for reducing signaling
 9   costs and preventing the HLR/AC from becoming a bottleneck.

10   2.4.4 Challenge/Response mechanism

11   Authentication is based on a challenge/response mechanism. This mechanism involves the
12   serving network challenging the MS with a randomly generated value. The MS uses this
13   challenge value along with its SSD and other information such as its ESN as inputs into the
14   CAVE algorithm to generate an authentication signature.

15   As shown below, this authentication signature is sent by the MS as a response to the
16   network’s challenge. As this document focuses on authentication in the context of roaming,
17   the scenario shown below is that of a roamer being authenticated by a visited network .
18   However, the mechanism is conceptually the same for a non-roaming scenario.




CDG #138, Rev 0.34                               November 8, 2011                                                     7
CDMA Authentication                                                                  Authentication Overview




                SSD


       A-key



               HLR/AC
                                                                                           SSD
           Home Network
                                  SSD                  Challenge (Challenge Value)


                                                        Response (Auth Signature)             A-key


                                MSC/VLR


 1
                               Visited Network

 2                         Figure 2-3: Challenge/Response Mechanism


 3   If SSD has been shared with the serving network, the MSC/VLR performs the same
 4   calculation. If the SSD has not been shared, the MSC/VLR proxies the authentication
 5   signature from the MS to the home HLR/AC where this calculation will be performed. In
 6   either case, the authentication signature calculated by the network (i.e. HLR/AC or
 7   MSC/VLR) is compared to the one calculated by the MS to determine whether the MS is
 8   authentic.
 9   This mechanism works because, in order for the calculated values to match, the SSD input
10   that was used by the network during its calculation must be the same as the SSD input that
11   was used by the MS. Essentially, authentication provides the network with a way to ensure
12   that the MS possesses correct SSD.


13   2.5 Elements involved in authentication
14   2.5.1 A-key Management System (AKMS)

15   The A-key Management System (AKMS) refers to the system by which a carrier securely
16   manages A-key values. This typically involves secure retrieval, random generation, storage,
17   and distribution of A-key values. The purpose of the AKMS is to ensure that A-key values
18   remain secure while enabling them to be provisioned into both the HLR/AC and MS. Ideally,
19   the AKMS is a dedicated, secure element maintained by the carrier; however, in practice, it
20   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
23   Authentication Center (AC) is where A-key information for each subscriber is stored. When
24   a new subscriber is activated, the A-key value provisioned in the MS must also be
25   provisioned in the AC.



CDG #138, Rev 0.34                           November 8, 2011                                             8
CDMA Authentication                                                                 Authentication Overview




 1   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,
12   the Visitor Location Register (VLR) interacts with the roaming MS during authentication. If
13   SSD is not shared, the MSC/VLR simply proxies authentication signaling between the
14   HLR/AC and the MS. However, the more common scenario is for SSD to be shared.
15   When SSD is shared, the MSC/VLR locally performs authentication signature calculation
16   and comparison. This approach both reduces signaling between home and visited networks
17   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
20   provisioned in the home HLR/AC associated with that subscriber. To participate in
21   authentication procedures, the MS must have the CAVE algorithm and be capable of using
22   this algorithm to generate new SSD during SSD update procedures and authentication
23   signatures during challenge/response procedures.
24   Basically, all new CDMA handsets are authentication capable. Many new handsets also
25   support removable user identity modules (R-UIM). If the MS uses an R-UIM, the CAVE
26   algorithm will reside on this R-UIM and all authentication calculations using CAVE will be
27   performed by the R-UIM. Otherwise, the MS will perform these calculations.




CDG #138, Rev 0.34                             November 8, 2011                                          9
CDMA Authentication                                                             Managing and Provisioning A-keys




 1              3. Managing and Provisioning A-keys

 2   The management and provisioning of A-key values is controlled by an element known as the
 3   A-Key Management System (AKMS). This element provides for secure retrieval, random
 4   generation, storage, and distribution of A-key values. The AKMS ensures that A-key values
 5   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
 9   to be generated by the manufacturer and pre-programmed into the MS at the factory. When
10   this method is used, the manufacturer must also provide the ESN/A-key information to the
11   carrier for storage in the AKMS as illustrated below. Before activating a pre-programmed
12   MS, the AKMS must provision the ESN and A-key associated with the MS into the AC.


                                 Carrier                     Manufacturers


                                             ESN / A-key         Manufacturer
                                             information            AAA


                                                                 Manufacturer
                                            Secure EDI or
                              AKMS                                  BBB
                                            encrypted file


                                                                 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
16   approaches are commonly used. The first, and most robust, approach involves the use of
17   an Electronic Data Interchange (EDI) between the manufacturer’s database subsystem and
18   the carrier’s AKMS. This approach allows the AKMS to directly retrieve A-key information
19   from a manufacturer’s database subsystem with no risk of exposing the information to
20   anyone within the carrier organization. However, while this solution works very well, smaller
21   carriers often do not have access to an EDI infrastructure.

22   The second, and more widely used, approach involves the manufacturer providing the
23   carrier with an encrypted file containing the list of ESN/A-key pairs. The carrier then typically
24   uses a script to automatically decrypt and upload this information into the AKMS. This
25   method is somewhat less secure than the EDI infrastructure approach since a person with



CDG #138, Rev 0.34                             November 8, 2011                                              11
CDMA Authentication                                                        Managing and Provisioning A-keys




 1   access to the script could potentially decrypt and access the contents of the file. However,
 2   many carriers find this approach to be an equitable tradeoff between security and cost-
 3   effectiveness.

 4   3.1.2 A-key generated by carrier
 5   The carrier’s AKMS typically provides for the secure generation of random A-key values. In
 6   addition to supporting activation of mobile stations without pre-programmed A-key values,
 7   this capability provides the flexibility to re-program legitimate mobile stations with new A-key
 8   values in cases where fraud has been detected.

 9   Practices such as using all zero default A-key values are not recommended since they allow
10   the A-key to be easily guessed by fraudsters, thereby compromising the effectiveness of
11   authentication. Whether provisioned by the manufacturer or AKMS, A-keys should always
12   be securely and randomly generated and protected from being viewed to the greatest extent
13   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
17   storage in the AKMS or generated by the AKMS itself. In either case, in order for service to
18   be activated, an A-key value must be provisioned into the AC as illustrated below.


                                Secure         A-key            A-key
                             provisioning or
                             OTASP A-key               AKMS                AC
                               generation
19



20                                  Figure 3-2: Provisioning the AC


21   Since both the AKMS and AC reside within the carrier’s network, the mechanism by which
22   the AKMS provides MIN/ESN/A-key information to the AC is an internal issue. However,
23   because the A-key is involved, the transfer of information between these entities should be
24   secure and protected from being viewed to the greatest extent practicable. Wherever
25   possible, it is recommended that automated methods of retrieving the A-key from the AKMS
26   and provisioning it into the AC during activation be used.

27   Some implementations involve A-key values being internally generated by the AC. In such
28   cases, the AKMS function is essentially incorporated into the AC and there is no transfer of
29   A-key information between AKMS and AC entities.




CDG #138, Rev 0.34                              November 8, 2011                                        12
CDMA Authentication                                                             Managing and Provisioning A-keys




 1   3.2.2 Provisioning the MS

 2   Provisioning of the MS may be implemented in several ways. The following subsections
 3   discuss various methods that are available to carriers to facilitate the provisioning of A-key
 4   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
 7   manufacturer is the most common method currently in use. When this method is used, the
 8   manufacturer will also provide the pre-programmed A-keys to the carrier’s AKMS where they
 9   are stored until needed for service activation. This scenario is illustrated below.

                                      A-key
                                              Manufacturer
                                               database

                                                        A-key

                                                                A-key

                                                AKMS                       AC
10

11                        Figure 3-3: A-key programmed by manufacturer


12   Pre-programmed A-keys are not mutually exclusive with the use of other methods discussed
13   herein to program an A-key into an MS. In other words, the fact that an MS has been pre-
14   programmed with an A-key value by the manufacturer does not prevent the carrier from
15   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
18   retailer. The secure approach to enabling retailer provisioning of mobile stations is for the
19   retailer to utilize an MS programming device (e.g. Synacom Validator) that communicates
20   directly with the carrier’s AKMS to retrieve A-keys as illustrated below.

                              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
24   allows the A-key to be securely retrieved from the AKMS and protected from view by the


CDG #138, Rev 0.34                              November 8, 2011                                             13
CDMA Authentication                                                         Managing and Provisioning A-keys




 1   retailer. This approach also removes the potential for human error in entering the A-key by
 2   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   Perhaps the most flexible option for programming the A-key into the MS is the use of Over-
 5   The-Air Service Provisioning (OTASP). MAP support for OTASP was introduced in IS-725
 6   with support for Over-The-Air Parameter Administration (OTAPA) added in IS-725-A.
 7   OTASP/OTAPA support in IS-725-A was later incorporated into TIA-41-E. For more
 8   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
10   This final approach involves a subscriber, retailer, or technician calling the carrier’s customer
11   care center from a working phone to obtain the A-key. Once the caller has been determined
12   to be legitimate, customer care requests a new A-key value from the AKMS. The AKMS
13   securely and randomly generates the new A-key value and provides this value to both
14   customer care and the AC. Customer care may then provide the A-key value to the caller for
15   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
19   provide greater security and less user interaction, this approach is more often used for
20   troubleshooting than new service activation. However, if carriers do choose to use this
21   approach for new service activation, it is recommended that they also have fraud detection
22   systems in place to detect excessive SSD updates that would occur when legitimate A-keys
23   are being programmed into cloned mobile stations.




CDG #138, Rev 0.34                             November 8, 2011                                          14
CDMA Authentication                                                                    Home versus local authentication




 1                       4. Home versus local authentication

      2   Authentication of a roaming MS may be
      3   performed by the roamer’s home system                               Auth required

      4   or locally by the system to which the MS
      5   is attempting to gain access. However,
                                                                       NO        Visited          YES
      6   roaming partners most commonly                                      supports local
      7   choose to support local authentication                                  auth
      8   because of its advantages in reducing                                                      AC
                                                                                           NO    shares SSD
      9   signaling between visited and home
                                                                                                 with visited
     10   systems. The two primary requirements                                                     VLR
     11   for supporting local authentication
                                                                                                         YES
     12   include: (1) the ability of the visited VLR
                                                                 Home                               Local
     13   to support CAVE algorithms for local
                                                             authentication                     authentication
     14   calculation of authentication signatures      18

     15   and (2) the willingness of the home           19          Figure 4-1: Home versus local
     16   system to share SSD with the visited          20                  authentication
     17   VLR to enable these calculations.

21        As illustrated to the right, if either of the two requirements are not met, authentication must
22        be performed by the home system. The visited system can inform the home system of its
23        ability to support local authentication using the TIA-41 SystemCapabilities (SYSCAP)
24        parameter.


25        4.1 Authentication by home system
26        To support home system based authentication, parameters and authentication signatures
27        must be relayed between the visited and home systems using TIA-41 messages. The figure
28        below illustrates the path of signaling when the roamer’s home system performs
29        authentication.



                 A-key
                                                                                                 A-key


                               MSC                            SS7                                AC
                                             VLR                                  HLR
                  SSD                                                                            SSD
                 COUNT                                                                          COUNT


                         Visited System                                            Home 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
33        challenges which are often performed on every system access attempt (e.g. registration,


CDG #138, Rev 0.34                                  November 8, 2011                                                15
CDMA Authentication                                                             Home versus local authentication




 1        origination, termination, data burst, etc…), home system based authentication results in a
 2        large amount of unnecessary SS7 signaling traffic between home and visited systems and
 3        burdens the home AC with generating the authentication signature for each challenge
 4        attempt. Of particular concern is the increased signaling traffic inherent in this approach
 5        because it directly results in additional costs to carriers and call delays to roamers.


 6        4.2 Local authentication by visited system
      7   The      more    common      approach      to
      8   authenticating roamers in a visited system
      9   involves the home AC sharing SSD with a                    A-key
     10   visited VLR so that authentication may be
     11   performed locally. Once SSD has been                                   MSC
                                                                                               VLR
     12   shared with the visited VLR, authentication
                                                                    SSD                        SSD
     13   may be performed by the visited system                   COUNT                      COUNT

     14   without involving the home system.
                                                                             Visited System
     15   Illustrated to the right, this approach
                                                          19
     16   distributes authentication closer to the
     17   roamer while disburdening the home AC and       20     Figure 4-3: Local authentication
     18   reducing network signaling and call delays.


21        Authentication signaling between the home and visited systems occurs during the initial
22        system access attempt (i.e. registration) before SSD and COUNT have been shared to
23        enable local authentication. However, once enabled, subsequent authentication attempts
24        are performed locally as illustrated in the above figure for the duration of time that the
25        roaming MS is registered in the visited network.

26        Note that the home system is not shown in the above figure since, once SSD has been
27        shared, local authentication does not require involvement from the home system. However,
28        in the event that a roaming MS were to fail local authentication, the visited system would
29        provide the home system with an authentication failure report (i.e. AFREPORT message).


30        4.3 SystemCapabilities (SYSCAP) of visited system
31        In order for a visited system to support local authentication, the VLR in this system must be
32        capable of supporting the CAVE algorithm and sharing SSD. These capabilities allow the
33        visited system to locally generate authentication signatures to compare against ones
34        received from the MS. The capability of the visited system to support the CAVE algorithm
35        and share SSD are indicated to a roamer’s home system via the SystemCapabilities
36        (SYSCAP) parameter.

37        SYSCAP is a required parameter in the AuthenticationRequest (AUTHREQ) message sent
38        from the visited network to the roamer’s home network. Therefore, when a roaming MS first
39        attempts to access a visited system with global challenges enabled, the home system is
40        notified of the system capabilities of the visited system via the AUTHREQ. If SYSCAP


CDG #138, Rev 0.34                                November 8, 2011                                           16
CDMA Authentication                                                      Home versus local authentication




 1   indicates that the visited network is capable of local authentication, the home system may
 2   enable SSD sharing by including SSD in the AUTHREQ response message (authreq) to
 3   allow subsequent system access attempts by the roaming MS in this visited system to be
 4   authenticated locally.

 5   SYSCAP is also a required parameter in authentication report messages (i.e. ASREPORT or
 6   AFREPORT) sent from the visited system to the home system to indicate the result of an
 7   authentication attempt. If SYSCAP indicates that the visited network is capable of local
 8   authentication, the home system may enable SSD sharing by including SSD in the
 9   authentication report response message (i.e. asreport or afreport) to allow subsequent
10   authentication challenges to the roaming MS in this visited system to be performed locally.


11   4.4 Enabling and disabling local authentication
12   The home system enables local authentication by “sharing” SSD with the visited VLR. Note
13   that while SSD is shared by the home system, the A-key is not. This approach protects the
14   A-key since it is never transmitted to the visited network and provides an extra layer of
15   security since the home system may initiate an SSD update process at any time if SSD is
16   believed to have been compromised.

17   Local authentication may be enabled or disabled (i.e. sharing of SSD information invoked or
18   revoked with the visited VLR) using any one of the following messages sent from the home
19   system to the visited system. Note that this occurs independently for each roaming MS, not
20   for the entire visited system.


21          4-1: Messages that may be used to enable or disable local authentication

                      Message       Description
                      AUTHDIR       AuthenticationDirective Invoke message
                      authreq       AuthenticationRequest Return Result
                      asreport      AuthenticationStatusReport Return Result
                      afreport      AuthenticationFailureReport Return Result

22   To enable local authentication (i.e. invoke sharing of SSD), the home system includes an
23   SSD parameter in one of the above messages sent to the visited system. If the
24   CallHistoryCount (COUNT) mismatch mechanism is being used for clone detection, a
25   COUNT parameter will also be included so that both SSD and COUNT are shared with the
26   visited system.

27   To disable local authentication (i.e. revoke sharing of SSD), the home system includes the
28   SSDNotShared (NOSSD) parameter in one of the above messages sent to the visited
29   system. If the COUNT mismatch mechanism is being used, COUNT will also have been
30   shared. Because the home system needs to retrieve this COUNT value from the visited
31   system, the AUTHDIR message is typically used to turn off SSD (and COUNT) sharing. Use
32   of AUTHDIR to revoke sharing is simply more efficient because COUNT may be included in


CDG #138, Rev 0.34                          November 8, 2011                                          17
CDMA Authentication                                                    Home versus local authentication




1   the AUTHDIR Return Response (authdir) from the visited network. Since there is no
2   response to authdir, asreport, or afreport return response messages, use of these messages
3   to turn off sharing would require an additional message transaction involving a
4   CountRequest (COUNTREQ) from home to visited system and COUNTREQ Return
5   Response (countreq) from visited to home system to retrieve the COUNT value.




CDG #138, Rev 0.34                         November 8, 2011                                         18
CDMA Authentication                                                                             Global Challenges




 1                                                         5. Global Challenges

      2   Global challenges are used by systems to
      3   ensure that all mobile stations attempting to
      4   access the system are authenticated.                                              Visited
      5   Mobile stations that roam into visited                                            System
      6   systems with global challenge enabled are
      7   requested     to    provide    authentication
                                                                       overhead message train
      8   parameters. The visited system indicates                         AUTH=1, RAND
      9   this request by setting the authentication bit
     10   (i.e. AUTH=1) in the overhead message
                                                           15
     11   train (OMT). The OMT should also include
     12   the global random challenge value (RAND)         16    Figure 5-1: Global challenge to MS
     13   to be used in generating the authentication
     14   result.

17        In response to the global challenge indicated by AUTH=1, authentication-capable mobile
18        stations will include the following authentication parameters in system access messages to
19        allow themselves to be authenticated in the visited network.


20         5-1: Authentication parameters provided by MS when global challenges are required

              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)

21        All system access attempts from the mobile will require these parameters to be included
22        when AUTH=1. System access attempts may include registration, origination, termination
23        (i.e. page response or reconnect), and data burst (e.g. SMS) messages.


24        5.1 Authentication signature (AUTHR)
25        The basis for authentication is the ability for both the MS and the authentication controller
26        (i.e. visited VLR if SSD is shared or home AC if not) to generate authentication signatures
27        that may be compared. In the case of a global challenge, the authentication signature is
28        referred to as the authentication result (AUTHR) and is calculated using the Cellular
29        Authentication and Voice Encryption (CAVE) algorithm with inputs illustrated below.




CDG #138, Rev 0.34                                  November 8, 2011                                          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
                                                                CAVE               AUTHR (18-bit)
            Authentication Data (24-bit)                      algorithm             Authentication
            If origination, use the last 6 dialed                                     Signature
            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   The MS generates and includes an AUTHR value in all system access messages in the
 4   visited network. Upon receiving the AUTHR from the MS, the visited system may proceed
 5   with authentication locally or forward this AUTHR value to the roamer’s home network for
 6   authentication. Whether MS response to the global challenge is authenticated by the visited
 7   system or the roamer’s home system depends on whether SSD is shared with the visited
 8   VLR.


 9   5.2 Roamer authenticated by its home system
10   If SSD is not shared with the visited system, the AUTHR value returned by the MS and the
11   RAND value used by the MS to generate this AUTHR must be forwarded to the roamer’s
12   home system for authentication. The global challenge message flow is illustrated below for
13   the case in which SSD information is not shared with the visited VLR.


                       SSD                                                                 SSD
                                                    Visited                     Home
                                                    System                     HLR/AC


                          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                                  November 8, 2011                                           20
CDMA Authentication                                                                     Global Challenges




 1   Note that the RAND, not the RANDC, is forwarded to the home system. The RAND value,
 2   which was selected by the visited system, was used by the MS to generate an AUTHR value
 3   in response to the global challenge. Since the AC will need to use this same RAND to
 4   generate an AUTHR value to compare to the one received from the MS, the RAND is
 5   included in the AUTHREQ message sent to the home system.


 6   5.3 Roamer authenticated locally by the visited system
 7   If SSD is shared with the visited VLR, forwarding RAND and AUTHR information to the
 8   roamer’s home system for authentication is unnecessary. Because the visited system has
 9   the SSD required to generate an AUTHR value locally to compare to the one received from
10   the MS, authentication can be performed by the visited system without involving the
11   roamer’s home system.

12   A global challenge message flow is illustrated below for the case in which SSD information is
13   shared with the visited VLR.


                                   SSD                                 SSD
                                                             Visited
                                                             System


                                       overhead message train
                                           AUTH=1, RAND
                                         system access
                                      AUTHR, RANDC, COUNT

14

15               Figure 5-4: Global challenge message flow when SSD is shared


16   5.4 Pre-validation using RANDC
17   The RANDC consists of the 8 most significant bits of the RAND and is used by the base
18   station to pre-validate the system access message sent by the MS. The base station
19   compares the RANDC received from the MS to the 8 most significant bits of the active
20   RAND being broadcast on the OMT. While a system may discard a system access
21   message if a mismatch is detected, the mismatch does not necessarily indicate that the MS
22   attempting to access the system is fraudulent, only that a cloned MS scenario may exist.
23   For example, a mismatch could occur when an MS in a border area uses a RAND value
24   being transmitted by a neighboring system or when an MS fails to receive the RAND value
25   being transmitted and uses a default value (i.e. RAND = 0).




CDG #138, Rev 0.34                           November 8, 2011                                         21
CDMA Authentication                                                                       Global Challenges




 1   5.5 Clone detection using COUNT
 2   CallHistoryCount (COUNT) is a counter value maintained by the roaming MS, home AC,
 3   and, if local authentication is enabled, the visited VLR. Used during the global authentication
 4   process, this counter provides a mechanism for detecting cloned mobile stations, especially
 5   when SSD and/or A-key values have been compromised.

 6   When a system access message is received in the visited system, the COUNT value
 7   provided by the roaming MS is compared with the one maintained by the authentication
 8   controller to determine whether they are consistent. A mismatch suggests that a clone may
 9   exist but is not necessarily a conclusive indication of cloning since RF transmission issues
10   may result in occasional minor mismatches. However, there should not be a large delta
11   between these values.

12   The policies of the authentication controller will determine whether to allow access, issue a
13   unique challenge, or deny access based on a COUNT mismatch. However, cases of large
14   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.
17   This algorithm typically updates the value at irregular intervals rather than simply
18   incrementing it with each call. To initiate an update, the AC sends an TIA-41 UpdateCount
19   parameter to the visited system as illustrated below.



                                               Visited                         Home
                                               System                         HLR/AC

                                                             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
23   UpdateCount parameter may be included by the home AC in any of the following messages
24   sent to the visited system to initiated the COUNT update procedure:




CDG #138, Rev 0.34                            November 8, 2011                                          22
CDMA Authentication                                                                  Global Challenges




 1      5-2: Messages that may contain UpdateCount to initiate COUNT update process

                      Message         Description
                      AUTHDIR         AuthenticationDirective Invoke message
                      authreq         AuthenticationRequest Return Result
                      asreport        AuthenticationStatusReport Return Result
                      afreport        AuthenticationFailureReport Return Result


 2   5.6 Reporting of results to roamer’s home system
 3   If SSD is shared with the visited network and the MS fails the global challenge, an
 4   AuthenticationFailureReport Invoke (AFREPORT) message will be sent by the visited
 5   system to inform the roamer’s home system of the failure as illustrated below. Reports of
 6   successful global challenges in the visited network are unnecessary. Likewise, results of
 7   global challenges when SSD is not shared need not be reported since the home system is
 8   the one performing the authentication.

                                         Global challenge




                                   No         SSD           Yes
                                             Shared



                         Authentication is             Fail        Auth Success
                        performed by the
                                                                  Result
                       home system so no
                       reporting is needed


                                                AFREPORT                 no report
 9

10                   Figure 5-6: Authentication reporting for unique challenges


11




CDG #138, Rev 0.34                            November 8, 2011                                     23
CDMA Authentication                                                                                Unique Challenges




 1                                                          6. Unique Challenges

      2   Unlike global challenges that require all
      3   mobile stations to provide authentication                                                Visited
      4   parameters before accessing the system,                                                  System
      5   a unique challenge is directed at a
      6   specific   mobile    station.     Unique                        authentication challenge
                                                                                  RANDU
      7   challenges may be used instead of or in
      8   addition to global challenges and may be
      9   initiated by either visited or home                12
     10   systems, regardless of whether SSD is
     11   shared.                                            13      Figure 6-1: Unique challenge to MS

14        Roaming mobile stations being uniquely challenged in a visited system will receive a unique
15        challenge message as shown above. This message may be received over paging, access,
16        or dedicated traffic channels.


17        6.1 Authentication signature (AUTHU)
18        As with the global challenge, the basis for authentication is the ability for both the MS and
19        the authentication controller (i.e. visited VLR or home AC) to generate authentication
20        signatures that may be compared. In the case of a unique challenge, the authentication
21        signature is referred to as the AuthenticationResponseUniqueChallenge (AUTHU) and is
22        calculated using the CAVE algorithm with inputs illustrated below. Note that the inputs used
23        in generating AUTHU for unique challenges differ from the inputs used in generating AUTHR
24        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
                                                                    CAVE              AUTHU (18-bit)
                 Authentication Data (24-bit)                     algorithm            Authentication
                 IMSI_S1 (i.e. last 6 digits of MIN)                                     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
28        unique challenge response message. The visited system compares the AUTHU value



CDG #138, Rev 0.34                                     November 8, 2011                                          25
CDMA Authentication                                                                             Unique Challenges




 1   received from the MS with the AUTHU value either generated by the visited VLR or received
 2   from the home AC to determine whether the MS is authentic. Unlike the global challenge,
 3   comparison of AUTHU values is always performed by the visited system, even when the
 4   challenge is initiated and AUTHU value generated by the home system.


 5   6.2 Unique challenge initiated by roamer’s home system
 6   A roamer’s home system may initiate a unique challenge at any time and regardless of
 7   whether SSD has been shared with the visited VLR. In fact, even if SSD has been shared
 8   and the visited network has successfully performed global and unique challenges on the
 9   roamer, the home system may still initiate a unique challenge at its discretion.

10   If the unique challenge is initiated by the home system, the AUTHU will be generated by the
11   home AC and provided to the visited system in an Authentication Directive (AUTHDIR)
12   message      as     shown      below.        This   AUTHDIR     will  also    include   the
13   RandomVariableUniqueChallenge (RANDU) that was used to generate the AUTHU.


                 SSD                                                                           SSD
                                                  Visited                              Home
                                                  System                              HLR/AC

                                                                 AUTHDIR
                                                               RANDU, AUTHU

                                                                   authdir
                       authentication challenge
                               RANDU

                       auth challenge response
                               AUTHU
                                                                 ASREPORT
                                                            unique challenge report

                                                                   asreport


14

15              Figure 6-3: Unique challenge initiated by roamer’s home system


16   Because the visited system performs the comparison of AUTHU values generated by the MS
17   and home system, results of the unique challenge must be reported to the home system
18   regardless of whether the challenge succeeds or fails.




CDG #138, Rev 0.34                            November 8, 2011                                                26
CDMA Authentication                                                                                Unique Challenges




 1   6.3 Unique challenge initiated locally by visited system
 2   If SSD is shared with the visited VLR, the visited system is able to initiate a unique challenge
 3   and generate an AUTHU locally to compare to the one received from the MS. The call flow
 4   for a visited system initiated unique challenge is illustrated below.


               SSD                                        SSD                                SSD
                                                Visited                              Home
                                                System                              HLR/AC


                     authentication challenge
                             RANDU

                     auth challenge response
                             AUTHU


                                                               AFREPORT
                                                          unique challenge report       Failure report
                                                                                        is only sent if
                                                                                        the unique
                                                                 asreport               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
 8   reported to the home system if the challenge fails; otherwise, the home system is not
 9   involved in the authentication attempt.


10   6.4 Reporting results to roamer’s home system
11   When a roamer’s home system initiates a unique challenge, the visited system will send an
12   AuthenticationStatusReport Invoke (ASREPORT) message upon completing the challenge
13   attempt to inform the home system whether the authentication was successful. However,
14   when unique challenges are initiated locally by the visited system, the home system only
15   needs to be informed of failed authentication attempts as illustrated below.




CDG #138, Rev 0.34                                November 8, 2011                                               27
CDMA Authentication                                                                    Unique Challenges




                                     Unique challenge




                       Home System       Challenge            Visited System
                                        initiated by



                        Success or                     Fail       Auth    Success
                         Failure                                 Result




                       ASREPORT               AFREPORT                     no report
1

2                    Figure 6-5: Authentication reporting for unique challenges


3




CDG #138, Rev 0.34                          November 8, 2011                                         28
CDMA Authentication                                                    Updating Shared Secret Data (SSD)




 1             7. Updating Shared Secret Data (SSD)

 2   The SSD update process allows new SSD information to be generated by both the home AC
 3   and roamer’s MS. Since this process relies on a MS having a legitimate A-key value
 4   provisioned, use of the SSD update process is an easy way to turn off service to a cloned
 5   MS that is using an illegally obtained SSD value. The SSD update process also allows
 6   roaming carriers that share SSD with their roaming partners to reduce security concerns by
 7   periodically changing SSD information.

 8   Depending upon manufacturer, an AC may provide multiple mechanisms for initiating SSD
 9   updates. These methods include automatic triggering based on a carrier defined algorithm,
10   periodic triggering based on a carrier defined interval, and manual triggering as needed.

11   The home AC begins the SSD update process by selecting a random number and using this
12   number along with ESN and A-key inputs into the CAVE algorithm to generate a new SSD
13   value. The home system then forwards this random number to the visited system using a
14   RandomVariableSSD (RANDSSD) parameter. Receipt of this RANDSSD parameter by the
15   visited system initiates the SSD update process to the MS, which may be in either idle or
16   traffic state. The home system may include the RANDSSD parameter in any of the following
17   messages sent to the visited system:


18         7-1: Messages that may contain RANDSSD to initiate SSD update process

                      Message        Description
                      AUTHDIR        AuthenticationDirective Invoke message
                      authreq        AuthenticationRequest Return Result
                      asreport       AuthenticationStatusReport Return Result
                      afreport       AuthenticationFailureReport Return Result


19   The SSD update process involves two authentication challenges. The first is a base station
20   challenge from the MS when the request to update SSD is received. The purpose of this
21   challenge is to allow the MS to verify that the SSD update request is being initiated from a
22   legitimate source. The second is a unique challenge after the MS has updated its SSD. The
23   purpose of this challenge is to validate that the new SSD value generated by the MS is
24   legitimate. Once both challenges are complete, the home system receives a status
25   message indicating whether the process was successful.

26   From the perspective of the roaming MS, the SSD update process is the same whether SSD
27   is shared with the visited system or not. The difference is that the non-shared scenario
28   places the burden of generating the AUTHU value and processing the base station
29   challenge on the home system and requires additional signaling between home and visited
30   systems. Most carriers prefer to share SSD with their roaming partners.




CDG #138, Rev 0.34                           November 8, 2011                                        29
CDMA Authentication                                                             Updating Shared Secret Data (SSD)




 1   7.1 SSD update process when SSD is shared
 2   In the shared SSD scenario, the new SSD value generated by the home AC is provided to
 3   the visited VLR along with the RANDSSD to initiate the update to the MS. The visited VLR
 4   uses this new SSD value to process base station and unique challenges during the SSD
 5   update process. Once these challenges are complete, the visited network sends an
 6   ASREPORT message containing SSD update and unique challenge reports to the home
 7   system to indicate the outcome of the SSD update process. The following diagram
 8   illustrates this process when SSD is shared with the visited network.


              SSD                                  SSD                         SSD
                                         Visited                       Home
                                         System                       HLR/AC

                                                     AUTHDIR
                                                                           Home system initiates
                                                   RANDSSD, SSD
                                                                           SSD update process by
                                                         authdir           including RANDSSD and
                       SSD update                                          shares new SSD value
                        RANDSSD                                            with the visited VLR.


                base station challenge                                     MS initiates a challenge
                      RANDBS                                               before updating its SSD
                                                                           to ensure that the update
                    challenge response                                     process is being initiated
                          AUTHBS                                           by a legitimate source.

                       SSD update
                        success                                            MS updates its SSD


                     unique challenge
                         RANDU                                             Unique challenge is used
                                                                           to validate the new SSD
                    challenge response                                     generated by the MS.
                          AUTHU


                                                  ASREPORT
                                                                           Reports sent back to
                                              SSDURPT, UCHALRPT
                                                                           home system to indicate
                                                         asreport          outcome of SSD update
                                                                           and unique challenge
 9

10                      Figure 7-1: SSD update process when SSD is shared


11   7.2 SSD update process when SSD is not shared
12   There are two major differences in the SSD update process when SSD is not shared with the
13   visited system. The first is that the home system, not the visited system, selects the RANDU
14   and generates the AUTHU required to perform the unique challenge during the SSD update
15   process. These RANDU and AUTHU values are included along with the RANDSSD when
16   the SSD update is initiated. The second is that rather than being processed locally by the



CDG #138, Rev 0.34                                 November 8, 2011                                           30
CDMA Authentication                                                             Updating Shared Secret Data (SSD)




1   visited system, the base station challenge from the MS is forwarded to the home system.
2   These differences are highlighted in red text in the following diagram illustrating.


              SSD                                                              SSD
                                         Visited                       Home
                                         System                       HLR/AC

                                                     AUTHDIR               Home system initiates
                                                     RANDSSD,              SSD update process by
                                                   RANDU, AUTHU            including RANDSSD and
                                                                           provides RANDU and
                       update SSD                      authdir             AUTHU values to enable
                        RANDSSD                                            visited system to perform
                                                                           unique challenge.

               base station challenge                                      MS initiates a challenge
                     RANDBS                           BSCHALL              before updating its SSD
                                                      RANDBS               to ensure that the update
                                                                           process is being initiated
                                                      bschall              by a legitimate source.
                    challenge response                AUTHBS               This challenge is
                          AUTHBS                                           forwarded to the home
                                                                           system to be processed.

                       SSD update
                        success                                            MS updates its SSD


                     unique challenge
                         RANDU                                             Unique challenge is used
                                                                           to validate the new SSD
                    challenge response                                     generated by the MS.
                          AUTHU


                                                  ASREPORT
                                                                           Reports sent back to
                                              SSDURPT, UCHALRPT
                                                                           home system to indicate
                                                      asreport             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                                 November 8, 2011                                           31
CDMA Authentication                                                                    Authentication Enhancements




 1                         8. Authentication Enhancements

 2   IS-778 defines various enhancements to the CAVE-based authentication mechanisms
 3   introduced in TIA-41-D. These enhancements have since been incorporated into TIA-41-E
 4   and include the following:

 5                           8-1: Authentication enhancements in IS-778
                 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   Except for the introduction of a new SuspiciousAccess parameter, IS-778 authentication
 7   enhancements leverage the same TIA-41-D authentication operations (e.g. AUTHDIR,
 8   AUTHREQ, etc…) and parameters. Details on selected authentication enhancements
 9   introduced in IS-778 are provided in the following subsections.


10   8.1 Roamers from a non-authentication-capable partner
11   When an authentication-enabled visited system attempts to support inbound roamers from a
12   non-authentication-capable home system, the home system is neither able to provide an
13   AuthenticationCapability (AUTHCAP) parameter indicating that authentication is not required
14   nor recognize an AUTHREQ message from the visited system. As a result, the
15   authentication-enabled visited system receives AUTHREQ Return Error of “Operation Not
16   Supported” during registration of a roaming MS from the non-authentication-capable home
17   system.

18   In TIA-41-D this error is treated as an authentication failure and the roamer is not able to
19   access the visited system. TIA/EIA-E addresses this scenario by modifying the behavior of
20   the visited MSC to proceed with registration and not attempt subsequent authentications with
21   the roamer’s home network. This TIA-41-E behavior is necessary if an authentication-
22   enabled system wishes to support roamers from a non-authentication-capable system.


23   8.2 Handling of suspicious call origination attempts
24   The new SuspiciousAccess (SUSACC) parameter is provided as a mechanism to allow a
25   visited system to inform a home system when their roamer’s call origination attempt in the
26   visited system is suspicious. When a suspicious access is identified, the SUSACC




CDG #138, Rev 0.34                               November 8, 2011                                              33
CDMA Authentication                                                                Authentication Enhancements




 1   parameter is included in the AUTHREQ sent to the home system. Receipt of the SUSACC
 2   parameter indicates to the home system that a unique challenge may be warranted.


            SSD                                                              SSD
                                       Visited                       Home
                                       System                       HLR/AC


               overhead message train
                   AUTH=1, RAND


                   system access                                          Visited system
               AUTHR, RANDC, COUNT,                                       determines that dialed
                    Digits (dialed)               AUTHREQ
                                                                          digits are suspicious
                                             AUTHR, RAND, COUNT,
                                                                          and includes the
                                             SUSACC, Digits (dialed)
                                                                          SUSACC parameter.

                                                     authreq
                                                  RANDU, AUTHU            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
 6   access attempt appears suspicious for reasons other than anomalous dialed digits, the
 7   primary scenario addressed by SUSACC is the receipt of extraneous digits in the number
 8   dialed by a roamer during call origination. These extraneous digits could indicate a replay
 9   attack that is attempting to circumvent global challenge authentication by appending
10   previously dialed digits to a new dialed number.

11   Global challenges are generally an effective tool against replay attacks since call origination
12   attempts use the last 6 digits of the dialed number to calculate the AUTHR value. One
13   would think it unlikely for a replay attempt to be useful since the fraudulent user could only
14   successfully pass authentication by dialing numbers ending in the same 6 digits. However, it
15   may be possible to circumvent the spirit of this limitation by appending the last 6 dialed digits
16   from the original attempt to the dialed number in the fraudulent replay attempt. While this
17   results in a dialed number that is 6 digits longer than it should be, when the dialed digits are
18   processed through the MSC translation tables, a route would be determined based on the
19   new dialed number before reaching these additional digits. Once the route is determined,
20   the MSC often ignores the remaining digits. The SUSACC parameter allows the MSC to
21   identify these additional digits as suspicious rather than ignoring them.

22   If SSD is shared with the visited VLR, an alternative approach could be to ensure that the
23   visited MSC policy triggers a locally initiated unique challenge when additional digits are
24   provided.




CDG #138, Rev 0.34                               November 8, 2011                                          34
CDMA Authentication                                                           Over-The-Air (OTA) Support




 1                             9. Over-The-Air (OTA) Support

 2   MAP support for Over-The-Air Service Provisioning (OTASP) was introduced in IS-725 with
 3   support for Over-The-Air Parameter Administration (OTAPA) added in IS-725-A.
 4   OTASP/OTAPA support in IS-725-A was later incorporated into TIA-41-E. The purpose of
 5   this section is to provide basic information on these mechanisms in the context of their
 6   support for authentication functions (e.g. A-key provisioning).


 7   9.1 OTASP
 8   Over-The-Air Service Provisioning (OTASP) provides carriers with a flexible and secure
 9   mechanism to support activation of service for new subscribers and updating of MS
10   provisioning information (e.g. A-key value, NAM programming, etc…) for existing subscribers
11   over the air interface. OTASP involves the subscriber initiating these actions by placing an
12   OTASP call to the Customer Service Center (CSC) from their MS. This call is typically
13   invoked by entering an OTASP feature code such as *228, followed by additional
14   information such as a system code, directory number, or system operator code. The dialing
15   format used to invoke an OTASP call is determined by the carrier. OTASP provides
16   subscribers with flexibility since they may activate or update their MS provisioning at any
17   time by simply placing a call rather than having to physically visit a service center.


18   9.2 OTAPA
19   Over-The-Air Parameter Administration (OTAPA) is similar to OTASP in that it supports
20   updating of NAM and other operational parameters in the MS over the air interface.
21   However, OTAPA is initiated autonomously by the network without involvement from the
22   subscriber. In fact, the subscriber is unaware of OTAPA updates when they occur. OTAPA
23   may be performed at anytime while the MS is powered on and does not interfere with the
24   subscriber’s use of the MS (i.e. if the subscriber attempts to use the MS while OTAPA is in
25   progress, the OTAPA is terminated). OTAPA provides carriers with flexibility since they may
26   update subscriber MS provisioning when needed without requiring the subscriber to take any
27   action.


28   9.3 OTASP/OTAPA mechanism
29   OTASP and OTAPA operations are controlled by an Over-The-Air Function (OTAF) that
30   communications via TIA-41 with the serving MSC and home HLR/AC. In the case of
31   OTASP, the OTAF also communicates with the Customer Service Center (CSC) via
32   proprietary messaging.

33   9.3.1 OTASP attachment

34   Because OTASP supports the activation of new mobile stations that have not been
35   provisioned, two things must occur at the serving MSC. First, since the MS may not be




CDG #138, Rev 0.34                           November 8, 2011                                        35
CDMA Authentication                                                                Over-The-Air (OTA) Support




 1   provisioned with an A-key, the MSC may need to allow unauthenticated OTASP calls to be
 2   routed to their home customer service centers. Second, the MSC must recognize the call as
 3   an OTASP call and assign a TemporaryReferenceNumber (TRN) to be included with the call
 4   (typically as the calling party number) when it is routed to the CSC. The OTAF uses this
 5   TRN to create as attachment between itself and the MSC as illustrated below.


                          Visited                      OTAF         CSC
                          System

            call origination                                              MSC recognizes OTASP
            OTASP FC + XX                                                 call attempt, selects
                               ISUP call (TRN)                            TRN, and routes call to
                                                                          CSC with TRN in either
                                Voice path connected                      the calling or called party
                                                                          number


                                                          proprietary     CSC provides received
                                        SMDPP                             TRN to OTAF. OTAF
                                                             TRN
                                       MIN, TRN,                          selects a MIN and
                                    ACTCODE, SRVIND                       initiates attachment by
                                                                          sending SMDPP with
                                        smdpp                             action code set to
                                     MS_MSID, ESN,                        “Attach MSC to OTAF”.
                                     MSCID, SYSCAP                        MSC responds with MS
                                                                          and MSC information

                                        SMDPP
                                                                          Attachment now setup.
                                     ACTCODE, MIN,
                                                                          OTAF sends SMDPP
                                      ESN, SRVID
                                                                          with action code set to
                                                                          “Release TRN” since
                                        smdpp
                                                                          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
 9   been provisioned.

10   9.3.2 Action codes

11   Each OTASP/OTAPA operation involves the OTAF sending an OTASPRequest
12   (OTASPREQ) message to the HLR/AC. In the case of an OTASP operation, the sending of
13   this message is a response to proprietary messaging with the CSC once a subscriber has
14   been connected to the CSC. In the case of an OTAPA operation, the trigger is defined by
15   the carrier without involvement from the subscriber. In either case, the OTASPREQ
16   message contains an ActionCode (ACTCODE) parameter that identifies the desired action to
17   be performed during the OTASP/OTAPA operation. New action codes defined in TIA-41-E
18   are shown below.




CDG #138, Rev 0.34                           November 8, 2011                                             36
CDMA Authentication                                                                    Over-The-Air (OTA) Support




 1                              9-1: New action codes defined in TIA-41-E

                     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   9.4 A-key generation procedure
 3   While OTASP and OTAPA may be useful for a variety of scenarios, this paper is interested
 4   in their use in the context of authentication. A primary use of these functions is that of an
 5   alternative to the A-key provisioning options discussed in section 3.2 A-key provisioning.
 6   While these previously discussed options are functional, each suffer from deficiencies in
 7   either flexibility or security.

 8   For example, while pre-programmed A-keys from the manufacturer are secure, they are
 9   inflexible without a mechanism to update the A-key if necessary. A-keys may be updated at
10   designated service centers, but this approach lacks flexibility since it requires the customer
11   to bring their MS to the service center. On the other hand, more flexibility may be provided
12   by allowing customers or retailers to provision A-key values, but this approach lacks security.

13   The A-key generation procedure supported by OTASP addresses each of these issues. Its
14   ability to be initiated by the subscriber at anytime provides flexibility while its use of a 512-bit
15   Diffie-Hellman key agreement algorithm for secure key exchange provides security. The
16   following illustrations provide a high-level view of the A-key generation procedure and call
17   flow for this procedure once an attachment has been made between the serving MSC and
18   OTAF.




CDG #138, Rev 0.34                                 November 8, 2011                                           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              Partial
                                                   keys                 keys             Generate
                                                             OTAF                AC       A-key
                     Partial
                      keys

            Generate                                                                MS and AC each locally
             A-key                                                                   generate same A-key
                                                            Customer
                                                                                     (actual A-key value is
                                                              Care
                                                                                     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                              Figure 9-2: OTASP A-key generation procedure



                                       Visited                                   OTAF                    HLR/AC
                                       System

                                                                                         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


3

4                                  Figure 9-3: A-key generation call flow


CDG #138, Rev 0.34                                   November 8, 2011                                                 38
CDMA Authentication                                                                      Over-The-Air (OTA) Support




 1   9.5 SSD update

 2   In addition to A-key generation, the OTAF may initiate the SSD update procedure discussed
 3   in the 7. Updating Shared Secret Data (SSD) section of this paper. The OTAF begins the
 4   SSD update procedure by sending an OTASPREQ message containing an ACTCODE set to
 5   “Perform SSD Update procedure” to the HLR/AC. Also included in this OTASPREQ
 6   message is an SRVIND parameter indicating either OTASP or OTAPA.


 7   As illustrated below, upon receiving the OTASPREQ, the HLR/AC proceeds with the SSD
 8   update procedure as normal. The only difference in SSD update call flow when this
 9   procedure is initiated by the OTAF is that each TIA-41 invoke message between HLR/AC
10   and MSC during the procedure includes the SRVIND parameter indicating OTASP or
11   OTAPA. Also note that shared SSD is not supported for OTASP/OTAPA sessions.
12   Therefore, new SSD is not included in the AUTHDIR sent to the visited system during an
13   OTAF-initiated SSD update.


         Visited                      OTAF                            HLR/AC
         System

                                              OTASPREQ
                                           MS_MSID, ACTCODE,              OTAF sends an OTASPREQ
                                          SYSCAP, MSCID, SRVID            message with action code set
                                                                          to “Perform SSD Update “


                                  AUTHDIR                                 HLR/AC proceeds with SSD
                           RANDSSD, RANDU, AUTHU,                         update procedure as normal.
                           SRVIND, MS_MSID, MSCID                         SRVIND, MS_MSID, and
                                                                          MSCID received from OTAF
                                                                          are included in the AUTHDIR.
                   Call flow proceeds as illustrated in Figure 7-2:       Messages between MSC and
                   SSD update process when SSD is not shared.             AC during the procedure will
                                                                          include the SRVIND.


                                                 otaspreq                 To complete the SSD update,
                                            SSDURPT, UCHALRPT             HLR/AC responds to the
                                                                          OTASPREQ and includes the
                                                                          SSD update and challenge
                                                                          reports received from the MSC.
14

15                          Figure 9-4: OTAF-initiated SSD update procedure




CDG #138, Rev 0.34                                  November 8, 2011                                            39
CDMA Authentication                                                                       Recommendations




 1                                                10. Recommendations
 2   10.1 A-key management recommendations
 3   A fundamental rule of A-key management in CDMA authentication is that allowing anyone
 4   access to the A-key creates potential for its fraudulent usage. The potential for exposing the
 5   A-key exists anytime it is transferred into or out of the AKMS. With this in mind, the following
 6   recommendations are offered.

 7   10.1.1 Protect A-key information between manufacturer and AKMS

 8   If pre-programmed A-keys are used, ESN/A-key pairs should be securely transferred from
 9   the manufacturer’s database subsystem to the carrier’s AKMS. For more information, refer
10   to 3.1.1 A-key generated by manufacturer.

11   10.1.2 Protect A-key information between AKMS and AC

12   The AC should be able to securely retrieve A-keys directly from the AKMS.             For more
13   information, refer to 3.2.1 Provisioning the AC.

14   10.1.3 Protect A-key information between AKMS and MS

15   Secure and non-intrusive methods such as pre-programmed A-keys, programming devices
16   that communicate directly with the AKMS, or OTASP are recommended for provisioning the
17   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   This is simply an aging principle that prevents sensitive data from being unnecessarily stored
20   in multiple places.


21   10.2 General authentication recommendations
22   Whether authentication must be enforced by the visited network should be agreed upon and
23   specified in the roaming agreement between roaming partners.               The following
24   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
27   visited network. For more information, refer to 5. Global Challenges.




CDG #138, Rev 0.34                            November 8, 2011                                          41
CDMA Authentication                                                                    Recommendations




 1   10.2.2 Use the COUNT mismatch mechanism

 2   Validation of COUNT during global challenge authentication provides a mechanism for
 3   detecting cloned mobile stations, especially when SSD and/or A-key values have been
 4   compromised. For more information, refer to 5.5 Clone detection using COUNT.

 5   10.2.3 Enable local authentication

 6   Local authentication reduces signaling between the home and visited systems and
 7   minimizes call setup delay during authentication. For more information, refer to 4.2 Local
 8   authentication by visited system.

 9   10.2.4 Perform an SSD update when activating a new MS

10   Explicitly performing an SSD update whenever new mobile stations are activated will ensure
11   that any MS with a default SSD value of zero is updated with an SSD value based on the
12   ESN, A-key, and RANDSSD. For more information on the SSD update process, refer to 7.
13   Updating Shared Secret Data (SSD).

14   10.2.5 Trigger fraud procedures on large or repeated COUNT mismatches

15   While a COUNT mismatch does not definitively indicate that an MS is a clone, large
16   discrepancies or repeated mismatches should trigger fraud procedures.   For more
17   information, refer to 5.5 Clone detection using COUNT.

18   10.2.6 Trigger a unique challenge when a cloned MS is suspected

19   If a cloned MS is suspected even after a successful global challenge, the unique challenge
20   mechanism allows the specific MS to be challenged to ensure that it possess correct SSD.
21   For more information, refer to 6. Unique Challenges.

22   10.2.7 Trigger an SSD update if cloning still suspected after unique challenge

23   If a cloned MS is still suspected after a successful unique challenge, the SSD update
24   process should be used to limit the carrier’s exposure in case the MS is a clone using valid
25   SSD and/or A-key information. For more information on the SSD update process, refer to 7.
26   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
29   configurable field to either deny or allow service to a user when authentication fails. If
30   authentication fails, service should be denied.




CDG #138, Rev 0.34                           November 8, 2011                                       42
CDMA Authentication                                                                      Recommendations




 1   10.3 Specific recommendations for identified scenarios
 2   10.3.1 Cloned MS – valid ESN and MIN
 3   A cloned MS is one that has been illegally programmed with ESN and MIN information
 4   associated with a legitimate subscriber. Because this subscriber information is sent over-
 5   the-air, it is susceptible to being intercepted by fraudsters using devices such as Cellular
 6   Cache Boxes that combine a scanner, computer, and mobile station. While the CDMA air
 7   interface makes this information much more difficult to intercept, many CDMA phones
 8   support the ability to switch down into analog (e.g. AMPS) mode to enhance coverage area.
 9   When in analog mode, legitimate subscriber information is quite easily intercepted.

10   Use of the global challenge authentication mechanism by a carrier will thwart the efforts of
11   fraudsters using cloned mobile stations. In a roaming scenario, insistence upon the use of
12   authentication by each roaming partner protects both visited and home systems.

13   10.3.2 Cloned MS – valid ESN, MIN, and SSD

14   Beyond the common scenario of a cloned MS using illegally obtained ESN and MIN
15   information is the scenario in which SSD has been compromised. If a cloned MS acquires
16   validated SSD associated with a legitimate MS, both the legitimate and the cloned MS will be
17   able to access the system.

18   The solution is the use of the SSD update process discussed in the 7. Updating Shared
19   Secret Data (SSD) section of this paper. Because only the legitimate MS possess a valid A-
20   key, only this legitimate MS will be able to generate a new SSD value that is valid.
21   Therefore, the SSD update process provides an effective way for the home carrier to deny
22   access to cloned mobile stations that are illegally using validated SSD information. Further,
23   because this process is transparent to users, the goal is accomplished without impacting the
24   user experience of legitimate subscribers.

25   10.3.3 Cloned MS – valid ESN, MIN, SSD, and A-key

26   A more problematic scenario may exist when an older MS that uses a removable EEPROM
27   to store authentication parameters is supported. Because the contents of this EEPROM,
28   including the A-key, can be read and copied with relative ease, a clone can be created that
29   is an exact working copy of the legitimate MS. In such a case, both the legitimate and the
30   cloned MS will be able to access the system and update SSD.

31   While at first glance it may appear that a compromised A-key renders the SSD update
32   process ineffective, however, in practice, updating the SSD does actually solve the problem,
33   albeit in a potentially more intrusive and indirect fashion. The reason is that only one of the
34   two mobile stations (legitimate MS or clone) may be active at any given time. If the
35   legitimate MS is active when SSD update is performed, its SSD will be updated and the
36   clone will no longer be able to access the system. This is the best scenario as it solves the
37   problem without impacting the user experience of the legitimate subscriber.




CDG #138, Rev 0.34                            November 8, 2011                                         43
CDMA Authentication                                                                       Recommendations




 1   However, if the cloned MS is active when SSD update is performed, its SSD will be updated
 2   and the legitimate subscriber will no longer be able to access the system. The legitimate
 3   subscriber would then need to contact customer service to have a new A-key provisioned in
 4   their MS and the clone will be deactivated. This, of course, is less desirable since it requires
 5   the subscriber to take action to restore their service; however, it would deny further access
 6   to the cloned MS. A prudent additional step would be to encourage subscribers to upgrade
 7   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
10   the last six digits of the dialed number as an input for generating the authentication
11   signature. The idea is that even a successful replay attack would be of little use since it
12   could only be used to dial other numbers that end in the same six digits. However, because
13   of the way in which routing-on-dialed-digits occurs in many MSCs, this mechanism may be
14   bypassed by appending these last six digits onto a new dialed number.

15   The solution is to support the SuspiciousAccess (SUSACC) parameter discussed in the 8.2
16   Handling of suspicious call origination attempts section of this paper. Use of this parameter
17   allows the visited system to inform the home system when a roamer’s call origination attempt
18   includes extraneous digits. In response the home system may use the unique challenge
19   mechanism to ensure that the roamer is legitimate. If the origination attempt is, indeed, a
20   replay attempt, this unique challenge will fail.

21




CDG #138, Rev 0.34                            November 8, 2011                                          44
CDMA Authentication                                                                AKA-based Authentication




 1                              11. AKA-based Authentication
                                                              rd
 2   Enhanced Subscriber Authentication (ESA) refers to 3 generation authentication intended
 3   to replace CAVE-based authentication currently implemented by CDMA carriers. This new
 4   form of authentication is based on 3GPP Authentication and Key Agreement (AKA) for
 5   UMTS. MAP support for AKA in CDMA networks is defined by IS-945 with air interface
 6   support included in all releases following CDMA2000 Rev C. Note, however, that in order to
 7   facilitate interoperability and allow for phased introduction of AKA among various CDMA
 8   carriers, devices and networks that support AKA should also support legacy CAVE-based
 9   mechanisms. IS-945 also updates authentication capabilities (AUTHCAP) and system
10   capabilities (SYSCAP) parameters to allow the visited and home systems to identify to one
11   another which forms of authentication are supported by the home system’s roaming MS and
12   the visited system’s MSC/VLR.

13   The major advantages of AKA include stronger and bilateral authentication support.
14   Stronger authentication is provided through the use of larger 128-bit authentication keys and
15   stronger SHA-1 hash function. Bilateral authentication is provided via an authentication
16   token passed to the MS during the AKA authentication challenge. The AKA challenge
17   mechanism is similar to a CAVE-based unique challenge from the perspective of the network
18   authenticating the MS. However, the addition of the authentication token provides the MS
19   with information that enables it to authenticate the network before completing the challenge.
20   This bilateral authentication capability prevents false base stations attacks that could disable
21   voice privacy or compromise private identity information.

22   While they are beyond the scope of this paper, it is worth mentioning additional security
23   features enabled by AKA that indicate the robust nature of AKA as a successor to CAVE.
24   Following the bilateral entity authentication, AKA allows for the generation of new cipher and
25   integrity keys (CK and IK, respectively). These 128-bit keys enable a security association
26   between the MS and the serving MSC for supporting advanced security services such as
27   signaling message data integrity, signaling information element encryption, and user data
28   encryption. Also generated is a 128-bit UIM authentication key (UAK) that is used to protect
29   against the threat of rogue mobile stations when dealing with UIMs. The MS and the home
30   AC each generate these keys independently. Keys generated by the home AC are provided
31   in authentication vectors to the visited network and are never transmitted over the air to or
32   from the MS.


33   11.1 Authentication vectors (AVs)
34   A fundamental concept in AKA is the authentication vector (AV). An AV is essentially a
35   group of information used for one AKA attempt. AVs are generated by the home AC and
36   distributed to the visited network. Each AV contains all information required by the visited
37   network to locally perform AKA with an AKA-enabled mobile station. To thwart replay




CDG #138, Rev 0.34                            November 8, 2011                                          45
CDMA Authentication                                                                          AKA-based Authentication




 1   attempts, each AV must be used for only one AKA attempt. In other words, each AKA
 2   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        Expected Response               Network        Cipher, Integrity, & UIM
              Number             (32, 64, or 128 bits)         Authentication    Authentication Keys
             (128 bits)                                           Token             (128 bits each)




                                  CON_SQN                         AMF                MAC_A
                                  Concealed                 Authentication           Message
                               Sequence Number             Management Field     Authentication Code
                                   (48 bits)                   (16 bits)             (64 bits)



                             SQN               AK
                            Sequence         Anonymity
                             Number             Key
                             (48 bits)        (48 bits)
 3



 4               Figure 11-1: Information contained in an authentication vector


 5   Similar to a CAVE-based unique challenge when SSD is not shared, AKA challenges involve
 6   both the random challenge number and challenge response value being generated by the
 7   home system and provided to the visited system to enable local authentication. In CAVE,
 8   these values (RANDU and AUTHU) are provided to the visited system as separate
 9   parameters. In AKA these values (RANDA and XRES) are part of the AV provided to the
10   visited system. During the AKA attempt, random challenge number (RANDA) and network
11   authentication token (AUTN) information from the AV is provided to the MS by the visited
12   network. More information about this process is provided later.


13   11.2 AKA authentication process
14   Similar to CAVE, AKA relies on an authentication key associated with the MS and available
15   only to the MS and its home AC. In CAVE, this key is known as the authentication key (A-
16   key). In AKA, the key is known as the master key (K).

17   Also similar to CAVE, AKA involves a challenge process that allows the network to
18   authenticate the MS. However, in AKA the information provided during this challenge also
19   enables the MS to authenticate the network, providing for bilateral authentication.




CDG #138, Rev 0.34                                   November 8, 2011                                             46
CDMA Authentication                                                                            AKA-based Authentication




 1   The diagram below provides a high-level graphical description of the AKA process. The
 2   purpose for this diagram is to show the concepts involved in AKA, not to identify specific
 3   message flow.



                                                                    Visited                             Home
                                                                    System                             HLR/AC

                                                                                 Request AVs
                                          Distribution
                                            of AVs         Store the            Provide AV list
                                                             AV list

                                                                        Select an AV from the stored list
                                                                        to use with this auth attempt.
         Generate AK                             auth request
                                               (RANDA, AUTN)            Include the RANDA & AUTN
         Use AK to derive SQN from
                                                                        values from this AV in the auth
         CON_SQN in AUTN
                                                                        request sent to the MS.
         Generate XMAC_A



         Does XMAC_A = MAC_A                  If not…auth reject
         received in AUTN?                                                       Auth of network
                                                                                   by the MS
         Is SQN fresh?                       If not…synch failure
                                                                                 Failure report

                         Generate RES
         Auth of                                auth response
                         Include RES in             (RES)
        MS by the        auth response                                  Does RES = XRES in the AV?
         network
                                                                              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.
 7   The grey dashed arrows (e.g. “If not, auth reject”), indicate failure scenarios in which the
 8   AKA attempt would not proceed and a failure report would be provided to the home system
 9   to indicate the reason for the failure. Otherwise, each phase assumes that the previous
10   phase completed successfully. These phases include:

11       1. Distribution of AVs
12              a. Authentication vectors (AVs) are generated by the home system and
13                  provided to the visited system in an AV list



CDG #138, Rev 0.34                               November 8, 2011                                                   47
CDMA Authentication                                                              AKA-based Authentication




 1       2. Authentication of the network by the MS
 2             a. The message authentication code (MAC_A) received from the network is
 3                  verified against the expected MAC_A (XMAC_A) generated by the MS
 4             b. The sequence number (SQN) received from the network is verified against
 5                  the SQN locally maintained by the MS
 6       3. Authentication of the MS by the network
 7             a. The authentication response (RES) received from the MS is verified against
 8                  the expected RES (XRES) received from the home system in the network
 9                  authentication token (AUTN)
10       4. Establishment of security association between MS and MSC
11             a. Cipher key (CK), integrity key (IK), and UIM authentication key (UAK) are
12                  generated by the MS in such a way that they are identical to the ones
13                  provided to the visited network in the AV
14             b. The security association between MS and MSC involves using these keys to
15                  support security services such as confidentiality and integrity

16   With the exception of the last, each of these phases will be expanded upon in greater detail
17   in the following sections. The last phase involves the establishment of a security association
18   following bilateral authentication between MS and network. This last phase enables security
19   features such as confidentiality and integrity that are beyond the scope of this paper.

20   While the example provided above involves the AKA being initiated by the visited network, it
21   is worth noting that, as in the case of unique challenges in CAVE, AKA may also be initiated
22   by the home system at any time. To initiate AKA, a home system would simply send an
23   authentication directive (AUTHDIR) containing the AV to be used for the AKA attempt. Upon
24   receiving the AV, the visited network would proceed with the AKA attempt as normal.


25   11.3 Distribution of authentication vectors
26   Since an AV may only be used once, the visited network must obtain a new AV each time
27   AKA is performed. With AKA potentially being performed on every system access attempt
28   by the MS, the process of obtaining new AVs from the home network for each AKA would
29   result in a significant signaling burden between visited and home systems. To prevent this
30   inefficiency, AKA allows the home system to generate multiple AVs and distribute these AVs
31   to the visited system using a single AV list parameter (AKAVL). The AVs in this list are
32   ordered by sequence number. The number of AVs in the list is limited by an AV count
33   parameter (AKAVC) provided by the visited system that indicates the maximum number of
34   AVs the visited system is willing to accept at one time.

35   Upon receiving the list of AVs from the home system, the visited system stores this list and
36   simply selects a new AV from the list for each subsequent AKA attempt with the MS. Since
37   each AKA attempt, whether successful or not, results in one AV being removed from the list,
38   the visited network also maintains a minimum threshold of AVs. If the number of AVs in the
39   list falls below this threshold, the visited network will request a new list from the home
40   system.


CDG #138, Rev 0.34                            November 8, 2011                                        48
CDMA Authentication                                                                  AKA-based Authentication




                                     Visited                       Home
                                     System                       HLR/AC

                                                                         Visited system doesn’t
              overhead message train                                     know if MS supports
                  AUTH=1, RAND                                           AKA so CAVE-based
                                                                         global challenge is used

                system access                                            SYSCAP included to
             AUTHR, RANDC, COUNT                 AUTHREQ                 indicate AKA support by
                                            AUTHR, RAND, COUNT,          visited system. AKAVC
                                              SYSCAP, AKAVC              used to indicate the max
                                                                         number of AVs expected

                                                    authreq              If the MS supports AKA,
                                                    AKAVL                a list of AVs is provided
                                                                         using AKAVL

                    auth request                                         Visited system selects
                   RANDA, AUTN                                           an AV from the received
                                                                         list and uses it to
                                                                         perform AKA auth

 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
 4   during an initial system access attempt. Because it is the initial system access attempt (e.g.
 5   registration), the visited system is unaware of the mobile station’s authentication capabilities.
 6   Since support for CAVE is assumed and AKA is unknown, the visited system initiates a
 7   CAVE-based global challenge to the MS and includes the MS response in an authentication
 8   request (AUTHREQ) to the home system. However, also included in this AUTHREQ are
 9   parameters to indicate that the visited system supports AKA and a request for AVs.

10   Since the home system is aware of the authentication capabilities of the MS, it may either
11   process the CAVE-based global challenge response (AUTHR) or return an AV list to allow
12   the visited system to use AKA. Returning an AV list implicitly indicates that the MS supports
13   AKA.


14   11.4 Authentication of the network by the MS
15   Authentication of the network by the MS involves an explicit validation that the home AC is
16   synchronized with the MS and an implicit validation that the AV information being used for
17   this authentication was generated by a home AC provisioned with the same master key (K)
18   as the MS. To ensure synchronization, a sequence number is provided by the network and
19   compared against the sequence number maintained by the MS. To validate the authenticity
20   of the message, a message authentication code (MAC_A) is provided by the network and
21   compared against an expected MAC (XMAC_A) computed by the MS.




CDG #138, Rev 0.34                             November 8, 2011                                           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
 3   48-bit anonymity key (AK). The result is the concealed SQN (CON_MS_SQN) which is
 4   provided to the MS in the network authentication token (AUTN). Because it is concealed,
 5   the SQN must be derived by the MS before it can validated. To derive the SQN from the
 6   CON_MS_SQN, the MS first generates an AK value using the f5 algorithm with inputs shown
 7   below.


               K (128-bit)
               Provisioned in MS & AC.                               AK

               RANDA (128-bit)
                                                         f5          (48-bit)

               Received in AV and sent to MS.

 8

 9                              Figure 11-4: Generation of AK for AKA


10   Since the MS and home AC are provisioned with the same master key (K), the AK generated
11   by the MS will be the same as the one used by the home AC to conceal the SQN. Once this
12   AK has been generated, the MS derives the SQN from the CON_MS_SQN and compares
13   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
16   synchronization problem exists between the network and the MS. In such a case, the MS
17   will respond to the authentication request with an authentication resynchronize message
18   (AURSYNM). To enable the network to resynchronize with the MS, the MS includes a
19   concealed version of its own SQN (CON_MS_SQN) as shown below. In addition to the
20   CON_MS_SQN, the MS also includes a message authentication code for resynchronization
21   (MAC_S). The purpose of the MAC_S is to allow the network to validate the authenticity of
22   the resynchronization request and prevent unauthorized devices from initiating
23   resynchronization.




CDG #138, Rev 0.34                              November 8, 2011                                     50
CDMA Authentication                                                                   AKA-based Authentication




                                  Visited                     Home
                                  System                     HLR/AC

                  auth request
                 RANDA, AUTN

              auth resynchronize            MS determines that the SQN contained in the AUTN
             CON_MS_SQN, MAC_S              does not match its locally stored SQN and responds
                                            with an auth resynchronize message

                                                                   Failure report sent with an
                                             AKAREPORT             AKARPT value of “Synch
                                               AKARPT,             Failure”. AUTS contains
                                             RANDA, AUTS           CON_MS_SQN & MAC_S
                                                                   values received from MS

                                               akareport           Home system uses AUTS info
                                                AKAVL              to synchronize with MS and
                                                                   provides a new list of AVs.

                  auth request
                                                                   Visited system reattempts AKA
                 RANDA, AUTN
                                                                   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
 4   status report (AKAREPORT) to the home system with AKARPT set to “Synchronization
 5   Failure.” Also included in this report are the RANDA used during the AKA attempt and an
 6   AKA authentication token for resynchronization (AUTS) containing the CON_MS_SQN and
 7   MAC_S values received from the MS.

 8   The home system uses the MAC_S to ensure that the resynchronization attempt is authentic
 9   and sets its SQN to the one concealed in the CON_MS_SQN. With the new SQN, the home
10   system then generates a new AV list and provides this new AV list to the visited network in
11   the AKAREPORT response message (akareport).

12   Now that the home system has resynchronized and provided a new list of AVs, the visited
13   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.
16   Using the f1 algorithm with inputs shown below, the MS generates an expected MAC_A
17   (XMAC_A) value to compare to the one provided by the network in the AUTN.




CDG #138, Rev 0.34                             November 8, 2011                                            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)                                                   MS: XMAC_A
               Derived from CON_SQN, which is
               part of AUTN received in AV and
                                                             f1               AC: MAC_A
                                                                              (64-bit)
               sent to MS

               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   The XMAC_A generated by the MS will only match the MAC_A received from the network if
 4   the master key (K) provisioned in the home AC is the same as the one provisioned in the
 5   MS. Therefore, by comparing XMAC_A with MAC_A, the MS can ensure that the AV being
 6   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
 9   generated by the MS, the MS will reject the authentication request as shown below.



                                         Visited                       Home
                                         System                       HLR/AC


                   auth request
                  RANDA, AUTN
                                                 MS determines that the MAC_A contained in the AUTN
                                                 does not match the XMAC_A value generated based
                      auth reject                on its master key and received RANDA & AUTH inputs

                                                     AKAREPORT              Failure report sent with an
                                                       AKARPT               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
13   status report (AKAREPORT) to the home system with an AKARPT set to “Reject.” Beyond
14   acknowledging the AKAREPORT with a return response (akareport), no further action is
15   taken by the home system.


CDG #138, Rev 0.34                                 November 8, 2011                                           52
CDMA Authentication                                                              AKA-based Authentication




 1   11.5 Authentication of the MS by the network
 2   Authentication of the MS by the network in AKA is similar to a unique challenge without
 3   shared SSD in CAVE. In both cases, the home system generates both the random
 4   challenge value that is sent to the MS and the response value that is expected from the MS.
 5   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)
 8   value and by the home AC to generate the XRES value.


               K (128-bit)
               Provisioned in MS & AC.                                MS: RES

               RANDA (128-bit)
                                                         f2           AC: XRES
                                                                      (32-128 bit)
               Received in AV and sent to MS.

 9

10                            Figure 11-8: Generation of (X)RES for AKA


11   If the RES value returned by the MS matches the XRES value contained in the AV being
12   used for the AKA attempt, the network is assured that the master key provisioned in the MS
13   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
16   system sends an AKA status report (AKAREPORT) to the home system with an AKARPT
17   value set to “Response Failure” as shown below.




CDG #138, Rev 0.34                              November 8, 2011                                      53
CDMA Authentication                                                               AKA-based Authentication




                          Visited                  Home
                          System                  HLR/AC

              auth request
             RANDA, AUTN

            auth response
                 RES


                                    AKAREPORT         RES from MS does not match XRES in
                                      AKARPT          AV. Failure report sent with an
                                                      AKAPRT value of “Response Failure.”

                                      akareport       Home system responds with AUTHDEN
                                     AUTHDEN,         set to “MS is not authorized” and the
                                    DENAUTHPER        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
4   with an authentication denied (AUTHDEN) parameter set to “MS is not authorized” and a
5   deny authentication period (DENAUTHPER) parameter set to the time interval that the
6   visited network should wait before attempting re-authorization with the MS.

7




CDG #138, Rev 0.34                          November 8, 2011                                           54
CDMA Authentication                                                                      References




 1                                                              12. References
 2   [1]    3GPP2 C.S0004-D (IS-2000.4-D); Signaling Link Access Control (LAC) Standard for
 3          cdma2000 Spread Spectrum Systems; v1.0; February 2004

 4   [2]    3GPP2 C.S0005-D (IS-2000.5-D); Upper Layer (Layer 3) Signaling Standard for
 5          cdma2000 Spread Spectrum Systems; v1.0; February 2004

 6   [3]    3GPP2 C.S0016-B (TIA-683-C); Over the Air Service Provisioning of Mobile Stations
 7          in Spread Spectrum Systems; v1.0; March 2003

 8   [4]    3GPP2 N.S0005-0 (TIA-41-D); Cellular Radiotelecommunications Intersystem
 9          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
13          Operations series of recommendations where xxx indicates document number:

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   [8]    3GPP2 X.S0006-0 (TIA-945); MAP Support of Authentication and Key Agreement
20          (AKA); v1.0; October 2005.

21




CDG #138, Rev 0.34                         November 8, 2011                                     55
CDMA Authentication                                                                         Terminology




1                                                          13. Terminology

      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.

                                                                 rd
      AKA             Authentication and Key Agreement. The 3 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.

                                                                           nd
      CAVE            Cellular Authentication and Voice Encryption. The 2 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.

                                                                                            rd
      ESA             Enhanced subscriber authentication. The general name for CDMA 3
                      generation authentication. AKA was selected to implement ESA.
                                             rd
                      References to CDMA 3 generation authentication typically use the
                      term AKA rather than ESA.




CDG #138, Rev 0.34                        November 8, 2011                                          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                         November 8, 2011                                          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                        November 8, 2011                                         59
CDMA Authentication                                                          TIA-41-D Authentication Reference




 1           14. TIA-41-D Authentication Reference
 2   14.1 TIA-41-D new relevant operations
 3   14.1.1 AuthenticationDirective (AUTHDIR)
 4   The AuthenticationDirective operation is used to request modification of an MS’s
 5   authentication parameters.
            Invoke Parameters                             Return Result Parameters
            ElectronicSerialNumber                  M     CallHistoryCount                         O
            MobileIdentificationNumber              M
            AuthenticationAlgorithmVersion          M
            AuthenticationResponseUniqueChallenge   O
            CallHistoryCount                        O
            DenyAccess                              O
            LocationAreaID                          O
            RandomVariableSSD                       O
            RandomVariableUniqueChallenge           O
            SenderIdentificationNumber              O
            SharedSecretData                        O
            SSDNotShared                            O
            UpdateCount                             O

 6   14.1.2 AuthenticationDirectiveForward (AUTHDIRFWD)

 7   The AuthenticationDirectiveForward operation is sent from the Anchor MSC toward the
 8   Serving MSC to request the initiation of a Unique Challenge to the indicated MS. This
 9   message can be relayed through the Tandem MSC(s).
            Invoke Parameters                             Return Result Parameters
            InterMSCCircuitID                       M     UniqueChallengeReport                    M
            MobileIdentificationNumber              M
            AuthenticationResponseUniqueChallenge   O
            RandomVariableUniqueChallenge           O

10   14.1.3 AuthenticationFailureReport (AFREPORT)

11   The AuthenticationFailureReport operation is used to report on the failure of an
12   autonomously initiated authentication operation for an MS.
            Invoke Parameters                             Return Result Parameters
            ElectronicSerialNumber                  M     AuthenticationAlgorithmVersion           O
            MobileIdentificationNumber              M     AuthenticationResponseUniqueChallenge    O
            ReportType                              M     CallHistoryCount                         O
            SystemAccessType                        M     DenyAccess                               O
            SystemCapabilities (Serving)            M     RandomVariableSSD                        O
            CallHistoryCount                        O     RandomVariableUniqueChallenge            O
            CallHistoryCountExpected                O     SharedSecretData                         O
            MSCID (Serving MSC)                     O     SSDNotShared                             O
            ReportType                              O     TerminalType                             O
            SenderIdentificationNumber              O     UpdateCount                              O



CDG #138, Rev 0.34                             November 8, 2011                                            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                   M      AuthenticationAlgorithmVersion           O
            MobileIdentificationNumber               M      AuthenticationResponseUniqueChallenge    O
            MSCID (Serving MSC)                      M      CallHistoryCount                         O
            SystemAccessType                         M      CDMAPrivateLongCodeMask                  O
            SystemCapabilities (Serving)             M      DenyAccess                               O
            AuthenticationData                       O      RandomVariableSSD                        O
            AuthenticationResponse                   O      RandomVariableUniqueChallenge            O
            CallHistoryCount                         O      SharedSecretData                         O
            ConfidentialityModes (Actual)            O      SignalingMessageEncryptionKey            O
            Digits (Dialed)                          O      SSDNotShared                             O
            PC_SSN (Serving MSC or VLR or HLR)       O      UpdateCount                              O
            RandomVariable                           O      VoicePrivacyMask                         O
            SenderIdentificationNumber               O
            TerminalType                             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
5   SSD is shared.
            Invoke Parameters                               Return Result Parameters
            ElectronicSerialNumber                   M      AuthenticationAlgorithmVersion           O
            MobileIdentificationNumber               M      AuthenticationResponseUniqueChallenge    O
            SystemCapabilities (Serving)             M      CallHistoryCount                         O
            CountUpdateReport                        O      DenyAccess                               O
            SenderIdentificationNumber               O      RandomVariableSSD                        O
            SSDUpdateReport                          O      RandomVariableUniqueChallenge            O
            UniqueChallengeReport                    O      SharedSecretData                         O
                                                            SSDNotShared                             O
                                                            UpdateCount                              O

6   14.1.6 BaseStationChallenge (BSCHALL)

7   Used to request a response to a Base Station Challenge Order received from an MS.
            Invoke Parameters                               Return Result Parameters
            ElectronicSerialNumber                   M      AuthenticationResponseBaseStation        M
            MobileIdentificationNumber               M
            RandomVariableBaseStation                M
            SenderIdentificationNumber               O

8   14.1.7 CountRequest (COUNTREQ)

9   Used to obtain the current value of the COUNT parameter.
            Invoke Parameters                               Return Result Parameters
            ElectronicSerialNumber                   M      CallHistoryCount                         M
            MobileIdentificationNumber               M
            SenderIdentificationNumber               O




CDG #138, Rev 0.34                               November 8, 2011                                            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
 3   RAND from a Border MSC corresponding to the RANDC received from an MS. This
 4   operation may be used if the value of RANDC received from an MS corresponds to a RAND
 5   value that may be transmitted by a Border MSC which is transmitting the same SID as the
 6   Serving MSC.
             Invoke Parameters                           Return Result Parameters
             MSCID (Serving MSC)                 M       RandomVariable                         O
             RANDC                               M       RANDValidTime                          O
             ServingCellID                       M



 7   14.2 TIA-41-D new relevant parameters
 8   14.2.1 AuthenticationAlgorithmVersion (AAV)

 9   May be sent with messages that also contain the SSD parameter to indicate the version (0
10   through 255) of CAVE algorithm that was used to calculate the SSD. If this parameter is not
11   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
14   for the mobile.

             Authentication Capability
             No authentication required.
             Authentication required.

15   14.2.3 AuthenticationData (AUTHDATA)

16   Contains the 24-bit authentication data used as input to CAVE for call origination.
17   AUTHDATA is derived from the information sent by the MS (e.g. last six dialed digits).

18   14.2.4 AuthenticationResponse (AUTHR)
19   Contains the 18-bit authentication response generated by an MS when accessing the
20   system (e.g., call origination, page response or autonomous registration). It is computed by
21   CAVE using the SSD of the MS and the RAND chosen by the visited MSC.

22   14.2.5 AuthenticationResponseBaseStation (AUTHBS)

23   Contains the 18-bit response to a Base Station Challenge Order, computed by CAVE using
24   the new SSD of the MS and the RANDBS chosen by the MS.

25   14.2.6 AuthenticationResponseUniqueChallenge (AUTHU)

26   Contains the MS’s 18-bit response to a Unique Challenge Order, computed by CAVE using
27   the SSD of the MS and the RANDU.




CDG #138, Rev 0.34                           November 8, 2011                                           63
CDMA Authentication                                                     TIA-41-D Authentication Reference




 1   14.2.7 CallHistoryCount (COUNT)

 2   Contains a 6-bit, modulo 64 (i.e. increments from 0 to 63 and wraps back around to 0), event
 3   counter used for clone detection. It is maintained by the MS and AC (and serving VLR if
 4   shared with the serving system). The events that result in incrementing the counter are
 5   defined by local administrative procedures at the AC (and at the VLR if shared with the
 6   serving system) and may include initial registration in a new serving MSC, call origination,
 7   page response, or periodically.

 8   14.2.8 CallHistoryCountExpected (COUNTEx)

 9   Contains a modulo 64 event counter which was expected from the MS. The value received
10   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.
             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
15   indicate why the access is being denied as shown below:

             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   Indicates which Random Variable was used by an MS to compute AUTHR. Values of the
18   RANDC may be coordinated between systems so that the RANDC also indicates which
19   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
22   authentication, Signaling Message Encryption, and digital channel Voice Privacy. The
23   random number is chosen by the Serving MSC.




CDG #138, Rev 0.34                                November 8, 2011                                    64
CDMA Authentication                                                      TIA-41-D Authentication Reference




 1   14.2.13 RandomVariableBaseStation (RANDBS)

 2   Contains a 32-bit random number that is used as input to the CAVE authentication algorithm
 3   for base station authentication. The random number is chosen independently by the MS
 4   during the process to update its SSD.

 5   14.2.14 RandomVariableSSD (RANDSSD)

 6   Contains a 56-bit random number that is used as input to the CAVE algorithm for generating
 7   Shared Secret Data (SSD-A and SSD-B). The random number is chosen independently by
 8   the AC during the process to update the MS’s SSD.

 9   14.2.15 RandomVariableUniqueChallenge (RANDU)

10   Contains a 24-bit random number that is used as input to the CAVE algorithm for
11   authenticating a specific MS. The random number is chosen independently by the AC or
12   VLR whenever a unique challenge is prescribed by local AC or VLR authentication
13   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
18   VLR) to the AC.

             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
21   SharedSecretData-B (SSD-B) used as a cryptovariable in Voice Privacy and Signaling
22   Message Encryption for an MS. SSD is computed only at the AC and at the MS since it is
23   based on the secret subscriber A-Key shared only between the AC and MS.




CDG #138, Rev 0.34                                 November 8, 2011                                    65
CDMA Authentication                                                              TIA-41-D Authentication Reference




 1   14.2.19 SSDNotShared (NOSSD)

 2   Used by the home system to indicate that the previously provided SSD is no longer valid and
 3   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
 6   values: not attempted, no response, successful, or failed.

            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
 9   voice privacy capabilities of the serving system.

            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).
            SE              Signaling message encryption not supported by the system.
                            Signaling message encryption supported by the system.
            VP              Voice privacy not supported by the system.
                            Voice privacy supported by the system.
            CAVE            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             SSD is not shared with the system for the indicated MS.
                            SSD is shared with the system for the indicated MS.

10   14.2.22 UniqueChallengeReport (UCHALRPT)

11   Indicates the outcome of the Unique Challenge initiated by the AC or the VLR using one of
12   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                               November 8, 2011                                              66
CDMA Authentication                                                             TIA-41-E Authentication Reference




 1            15. TIA-41-E Authentication Reference
 2   15.1 TIA-41-E updates to existing relevant operations
 3   Parameters that have been added to an operation in release E are shown in red and
 4   followed by an asterisk (*). Note that these parameters may not be new to release E, simply
 5   new to the operation as defined in release D; for example, because release E supports the
 6   RoutingDigits parameter in the AUTHREQ Return Result (authreq) operation, this parameter
 7   is shown as RoutingDigits*. While RoutingDigits is not new to release E, support for it in this
 8   operation is new. Likewise, parameters that have been removed from an operation in
 9   release E are shown in strikethrough grey.

10   15.1.1 AuthenticationDirective (AUTHDIR)

11   The AuthenticationDirective operation is used to request modification of an MS’s
12   authentication parameters. It is also used to transport encryption parameters to the Serving
13   MSC for CDMA OTASP, TDMA OTASP and CDMA OTAPA.
             Invoke Parameters                                  Return Result Parameters
             Unchanged, existing parms not shown       …        Unchanged, existing parms not shown   …
             MobileIdentificationNumber MSID*          M
             AuthenticationAlgorithmVersion            MO
             AuthenticationResponseReauthentication*   O
             CarrierDigits*                            O
             CaveKey*                                  O
             CDMAPrivateLongCodeMask*                  O
             DestinationDigits*                        O
             MobileStationMIN*                         O
             MSCID*                                    O
             RandomVariableReauthentication*           O
             RoutingDigits*                            O
             ServiceIndicator*                         O
             SignalingMessageEncryptionKey*            O
             VoicePrivacyMask*                         O

14   15.1.2 AuthenticationDirectiveForward (AUTHDIRFWD)

15   The AuthenticationDirectiveForward operation is sent from the Anchor MSC toward the
16   Serving MSC to request initiation of one or more authentication processes for the indicated
17   MS. This operation can be relayed through the Tandem MSC(s).
             Invoke Parameters                                 Return Result Parameters
             Unchanged, existing parms not shown       …       Unchanged, existing parms not shown    …
             MobileIdentificationNumber                MO      UniqueChallengeReport                  MO
             UpdateCount*                              O       CountUpdateReport*                     O
             IMSI*                                     O




CDG #138, Rev 0.34                                 November 8, 2011                                           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
 3   autonomously initiated authentication operation for an MS.
            Invoke Parameters                                 Return Result Parameters
            Unchanged, existing parms not shown        …      Unchanged, existing parms not shown    …
            MobileIdentificationNumber MSID*           M      CarrierDigits*                         O
            ReportType                                 O      DestinationDigits*                     O
            TerminalType*                              O      MobileIdentificationNumber*            O
                                                              RoutingDigits*                         O

 4   15.1.4 AuthenticationRequest (AUTHREQ)

 5   Used to request authentication of an authentication-capable MS.
            Invoke Parameters                                 Return Result Parameters
            Unchanged, existing parms not shown        …      Unchanged, existing parms not shown    …
            MobileIdentificationNumber MSID*           M      AnalogRedirectRecord*                  O
            CDMANetworkIdentification* (Serving MSC)   O      CarrierDigits*                         O
            ControlChannelMode*                        O      CaveKey*                               O
            ServiceRedirectionCause*                   O      CDMARedirectRecord*                    O
            SuspiciousAccess*                          O      DataKey*                               O
            TransactionCapability*                     O      DestinationDigits*                     O
                                                              MobileIdentificationNumber*            O
                                                              RoamingIndication*                     O
                                                              RoutingDigits*                         O
                                                              ServiceRedirectionInfo*                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
 8   SSD is shared.
            Invoke Parameters                                 Return Result Parameters
            Unchanged, existing parms not shown        …      Unchanged, existing parms not shown    …
            MobileIdentificationNumber MSID*           M      CarrierDigits*                         O
            EnhancedPrivacyEncryptionReport*           O      DestinationDigits*                     O
            MSCID* (Serving)                           O      MobileIdentificationNumber*            O
            ReauthenticationReport*                    O      RoutingDigits*                         O
            ServiceIndicator*                          O
            SignalingMessageEncryptionReport*          O
            VoicePrivacyReport*                        O

 9   15.1.6 BaseStationChallenge (BSCHALL)

10   Used to request a response to a Base Station Challenge Order received from an MS.
            Invoke Parameters                                 Return Result Parameters
            Unchanged, existing parms not shown        …      Unchanged, existing parms not shown    …
            MobileIdentificationNumber MSID*           M
            ServiceIndicator*                          O




CDG #138, Rev 0.34                                 November 8, 2011                                          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                                Return Result Parameters
            Unchanged, existing parms not shown      …       Unchanged, existing parms not shown     …
            MobileIdentificationNumber MSID*         M

 3   15.1.8 RandomVariableRequest (RANDREQ)

 4   Used by the Serving MSC to request the value of RAND from a Border MSC corresponding
 5   to the RANDC received from an MS. This operation may be used if the value of RANDC
 6   received from an MS corresponds to a RAND value that may be transmitted by a Border
 7   MSC which is transmitting the same SID as the Serving MSC.
            Invoke Parameters                                Return Result Parameters
            Unchanged, existing parms not shown      …       Unchanged, existing parms not shown    …
                                                             RandomVariable                         OM
                                                             RANDValidTime                          OM

 8   15.1.9 SMSDeliveryPointToPoint (SMDPP)

 9   General purpose operation used to convey a short message or in general any other
10   information or encapsulated data from one point to another point and report on the success
11   or failure of that transfer (for example, as used in SMS and CDMA OTASP).
            Invoke Parameters                                Return Result Parameters
            Unchanged, existing parms not shown      …       Unchanged, existing parms not shown    …
            ActionCode*                              O       AuthorizationDenied*                   O
            MobileIdentificationNumber MSID*         M       DenyAccess*                            O
            NewlyAssignedMIN*                        O       ElectronicSerialNumber*                O
            NewlyAssignedIMSI*                       O       MobileStationMIN MobileStationMSID*    O
            ServiceIndicator*                        O       MSCID*                                 O
            TemporaryReferenceNumber*                O       SystemCapabilities*                    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
15   Generation, SSD Update, and Commit/Release of a temporary A-key, etc.), and to also
16   return certain parameters.
            Invoke Parameters                                Return Result Parameters
            ActionCode                               O       AKeyProtocolVersion                    O
            AKeyProtocolVersion                      O       AuthenticationResponseBaseStation      O
            AuthenticationData                       O       BaseStationPartialKey                  O
            AuthenticationResponse                   O       DenyAccess                             O
            CallHistoryCount                         O       EnhancedPrivacyEncryptionReport        O
            ElectronicSerialNumber                   O       ModulusValue                           O
            MSID                                     O       OTASP_ResultCode                       O
            MobileStationMSID                        O       PrimitiveValue                         O
            MobileStationPartialKey                  O       SignalingMessageEncryptionReport       O




CDG #138, Rev 0.34                                November 8, 2011                                           69
CDMA Authentication                                                                 TIA-41-E Authentication Reference




            MSCID (Serving MSC)                          O         SSDUpdateReport                       O
            NewlyAssignedMSID                            O         UniqueChallengeReport                 O
            PC_SSN                                       O         VoicePrivacyReport                    O
            RandomVariable                               O
            RandomVariableBaseStation                    O
            ServiceIndicator                             O
            SystemCapabilities                           O
            TerminalType                                 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
4   fields added.

            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
            …                 Existing fields not shown…
            DP*               Data privacy is not supported by the system.
                              Data privacy is supported by the system.
            T-EPE*            TDMA enhanced privacy and encryption is not supported by the system.
                              TDMA enhanced privacy and encryption is supported by the system.




CDG #138, Rev 0.34                                   November 8, 2011                                             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
 4   selected by the AC.

             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   Contains the 18-bit authentication response generated by an MS for reauthentication. It is
 7   computed by the Auth_Signature procedure using the SSD of the MS and a RANDRA
 8   chosen by the AC.

 9   15.4.3 BaseStationPartialKey (BSKEY)

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   Contains the 32-bit random number that is used as input to the Auth_Signature algorithm for
17   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                                   November 8, 2011                                                 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                                  November 8, 2011                                                72
CDMA Authentication                                                         TIA-945 Authentication Reference




 1               16. TIA-945 Authentication Reference
 2   TIA-945 builds upon TIA-41-E recommendations to introduce MAP support of Authentication
 3   and Key Agreement (AKA).


 4   16.1 TIA-945 updates to existing authentication operations
 5   16.1.1 AuthenticationRequest (AUTHREQ)

 6   Parameters added.

             Invoke Parameters                            Return Result Parameters
             Existing parameters not shown…      …        Existing parameters not shown…         …
             AKA_VectorCount*                    O        AKA_AuthenticationVector*              O
                                                          AKA_AuthenticationVectorList*          O

 7   16.1.2 RegistrationNotification (REGNOT)

 8   Parameter added.

             Invoke Parameters                            Return Result Parameters
             Existing parameters not shown…      …        Existing parameters not shown…         …
             AKA_Report*                         O



 9   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                            Return Result Parameters
             MSID                                 M
             AKA_AuthenticationVector             O

12   16.2.2 AKARequest (AKAREQ)

13   Used to request new authentication vectors when the ability of the MS, the serving system,
14   and the home system to perform AKA has been established.

             Invoke Parameters                            Return Result Parameters
             MSID                                 M       AKA_AuthenticationVector               O
             MSCID (Serving MSC)                  M       AKA_AuthenticationVectorList           O
             SystemAccessType                     M       AuthorizationDenied                    O
             SystemCapabilities (Serving)         M       DeniedAuthorizationPeriod              O
             AKA_VectorCount                      O
             AUTS                                 O
             RANDA                                O




CDG #138, Rev 0.34                            November 8, 2011                                           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                                       M         AKA_AuthenticationVector                O
             MSCID (Serving MSC)                        M         AKA_AuthenticationVectorList            O
             SystemCapabilities (Serving)               M         AuthorizationDenied                     O
             AKA_Report                                 M         DeniedAuthorizationPeriod               O
             AKA_VectorCount                            O
             AUTS                                       O
             RANDA                                      O



 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.
             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
             …                Existing fields not shown…
             AKA*             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                                 November 8, 2011                                               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
 9   fewer than this, but not more.

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                                     November 8, 2011                                              75

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:49
posted:11/8/2011
language:English
pages:83