Fraud WG CDG138 CDMA Authentication

8/8/2019 Fraud WG CDG138 CDMA Authentication

1/81

CDMA Authentication

CDG Document 138

Version 0.34

Oct. 12, 2006

CDMA Development Group575 Anton Boulevard, Suite 560Costa Mesa, California 92626PHONE +1 888 800-CDMA

+1 714 545-5211FAX +1 714 545-4601

http://[email protected]

Notice

Each CDG member acknowledges that CDG does not review thedisclosures or contributions of any CDG member nor does CDGverify the status of the ownership of any of the intellectual propertyrights associated with any such disclosures or contributions.Accordingly, each CDG member should consider all disclosuresand contributions as being made solely on an as-is basis. If anyCDG member makes any use of any disclosure or contribution,then such use is at such CDG member's sole risk. Each CDGmember agrees that CDG shall not be liable to any person or

1

2

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

3
http://www.cdg.org/mailto:[email protected]://www.cdg.org/mailto:[email protected]


2/81

entity (including any CDG member) arising out of any use of anydisclosure or contribution, including any liability arising out ofinfringement of intellectual property rights.

1

2

1

2

3

3


3/81

CDMA Authentication Tables

Contents

CDMA Authentication...................................................................................................... .....i

CDG Document 138...............................................................................................................i

Version 0.34...........................................................................................................................i

Oct. 12, 2006....................................................................................................................... ...i

Contents.................................................................................................................................i

Figures................................................................................................................................vii

Tables....................................................................................................................................x

1. Introduction ......................................................................................................................1

2. Authentication Overview ................................................................................................ .3

2.1 What is cloning fraud ................................................................................................32.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 ..............................................................................10

3.1 A-key generation ............................................................................................... .....10

3.1.1 A-key generated by manufacturer ............................................................10

3.1.2 A-key generated by carrier .......................................................................11

3.2 A-key provisioning ..................................................................................................11

3.2.1 Provisioning the AC ..................................................................................11

3.2.2 Provisioning the MS .................................................................................12

CDG #138, Rev 0.34 December 5, 2010 i

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

4


4/81


4. Home versus local authentication ................................................................................14

4.1 Authentication by home system ..............................................................................14

4.2 Local authentication by visited system ....................................................................15

4.3 SystemCapabilities (SYSCAP) of visited system ....................................................15

4.4 Enabling and disabling local authentication ............................................................16

5. Global Challenges ..........................................................................................................18

5.1 Authentication signature (AUTHR) .........................................................................18

5.2 Roamer authenticated by its home system .............................................................19

5.3 Roamer authenticated locally by the visited system ...............................................20

5.4 Pre-validation using RANDC ............................................................................... ...20

5.5 Clone detection using COUNT ....................................................................... ........21

5.5.1 Updating CallHistoryCount (COUNT) .................................................... ...21

5.6 Reporting of results to roamers home system .......................................................226. Unique Challenges .........................................................................................................23

6.1 Authentication signature (AUTHU) .........................................................................23

6.2 Unique challenge initiated by roamers home system .............................................24

6.3 Unique challenge initiated locally by visited system .................................... ...........25

6.4 Reporting results to roamers home system ................................................. ..........25

7. Updating Shared Secret Data (SSD) ........................................................................... ..27

7.1 SSD update process when SSD is shared ........................................................ .....28

7.2 SSD update process when SSD is not shared .......................................................29

8. Authentication Enhancements ................................................................................. .....30

8.1 Roamers from a non-authentication-capable partner ................................ .............30

8.2 Handling of suspicious call origination attempts ................................................ .....30

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

9.1 OTASP ................................................................................................................. ..32

9.2 OTAPA ................................................................................................................. ..32

9.3 OTASP/OTAPA mechanism ...................................................................................32

9.3.1 OTASP attachment..................................................................................32

9.3.2 Action codes ............................................................................... .............33

9.4 A-key generation procedure ................................................................................ ...34

9.5 SSD update .......................................................................................................... ..36

10. Recommendations .................................................................................................. .....37

10.1 A-key management recommendations .................................................................37

10.1.1 Protect A-key information between manufacturer and AKMS ........... .....37

10.1.2 Protect A-key information between AKMS and AC .............................. ..37

CDG #138, Rev 0.34 December 5, 2010 ii

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

4


5/81


10.1.3 Protect A-key information between AKMS and MS ................... .............37

10.1.4 Delete A-keys from the AKMS once provisioned into MS and AC ..........37

10.2 General authentication recommendations ............................................................37

10.2.1 Use global challenges ............................................................................37

10.2.2 Use the COUNT mismatch mechanism ......................................... .......38

10.2.3 Enable local authentication ....................................................................38

10.2.4 Perform an SSD update when activating a new MS ............................. ..38

10.2.5 Trigger fraud procedures on large or repeated COUNT mismatches ....38

10.2.6 Trigger a unique challenge when a cloned MS is suspected ......... ..... ...38

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

10.2.8 Ensure that roaming partner denies service if authentication fails .... .... .38

10.3 Specific recommendations for identified scenarios ...............................................39

10.3.1 Cloned MS valid ESN and MIN ...........................................................3910.3.2 Cloned MS valid ESN, MIN, and SSD .................................................39

10.3.3 Cloned MS valid ESN, MIN, SSD, and A-key ......................................39

10.3.4 Replay attack with extra digits ................................................................40

11. AKA-based Authentication ..........................................................................................41

11.1 Authentication vectors (AVs) ......................................................................... .......41

11.2 AKA authentication process ..................................................................................42

11.3 Distribution of authentication vectors ....................................................................44

11.4 Authentication of the network by the MS ......................................................... .....45

11.4.1 Sequence number (SQN) ......................................................................46

11.4.2 Synchronization failure (i.e. SQN mismatch) ..................................... .....46

11.4.3 Message authentication code (MAC_A) .................................................47

11.4.4 AKA rejection by the MS (i.e. MAC_A mismatch) ...................................48

11.5 Authentication of the MS by the network ......................................................... .....49

11.5.1 Authentication response (RES) ..............................................................49

11.5.2 AKA authentication failure (i.e. RES mismatch) .....................................49

12. References ....................................................................................................................51

13. Terminology ..................................................................................................................52

14. TIA-41-D Authentication Reference .......................................................................... ..55

14.1 TIA-41-D new relevant operations ........................................................................55

14.1.1 AuthenticationDirective (AUTHDIR) .......................................................55

14.1.2 AuthenticationDirectiveForward (AUTHDIRFWD) ............................. .....55

14.1.3 AuthenticationFailureReport (AFREPORT) ............................................55

14.1.4 AuthenticationRequest (AUTHREQ) ................................................. .....56

CDG #138, Rev 0.34 December 5, 2010 iii

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

4


6/81


14.1.5 AuthenticationStatusReport (ASREPORT) ............................... .............56

14.1.6 BaseStationChallenge (BSCHALL) ........................................................56

14.1.7 CountRequest (COUNTREQ) ................................................................56

14.1.8 RandomVariableRequest (RANDREQ) ..................................................57

14.2 TIA-41-D new relevant parameters .......................................................................57

14.2.1 AuthenticationAlgorithmVersion (AAV) ...................................................57

14.2.2 AuthenticationCapability (AUTHCAP) ............................................... .....57

14.2.3 AuthenticationData (AUTHDATA) ..........................................................57

14.2.4 AuthenticationResponse (AUTHR) .........................................................57

14.2.5 AuthenticationResponseBaseStation (AUTHBS) ................................ ...57

14.2.6 AuthenticationResponseUniqueChallenge (AUTHU) .............................58

14.2.7 CallHistoryCount (COUNT) ....................................................................58

14.2.8 CallHistoryCountExpected (COUNTEx) ......................................... ..... ...5814.2.9 CountUpdateReport (COUNTRPT) ...................................................... ..58

14.2.10 DenyAccess (DENACC) .......................................................................58

14.2.11 RANDC ................................................................................................58

14.2.12 RandomVariable (RAND) ................................................................... ..59

14.2.13 RandomVariableBaseStation (RANDBS) ..................................... ..... ...59

14.2.14 RandomVariableSSD (RANDSSD) ................................................. .....59

14.2.15 RandomVariableUniqueChallenge (RANDU) .......................................59

14.2.16 RANDValidTime (RANDVT) ....................................................... ..... .....59

14.2.17 ReportType (RPTTYP) ................................................................. ..... ...59

14.2.18 SharedSecretData (SSD) ................................................................... ..60

14.2.19 SSDNotShared (NOSSD) ............................................................... .....60

14.2.20 SSDUpdateReport (SSDURPT) ........................................................ ...60

14.2.21 SystemCapabilities (SYSCAP) ........................................................ .....60

14.2.22 UniqueChallengeReport (UCHALRPT) ................................................60

14.2.23 UpdateCount (UPDCOUNT) ................................................................60

15. TIA-41-E Authentication Reference ................................................................. ...........61

15.1 TIA-41-E updates to existing relevant operations ............................................... ..61

15.1.1 AuthenticationDirective (AUTHDIR) .......................................................61

15.1.2 AuthenticationDirectiveForward (AUTHDIRFWD) ............................. .....61

15.1.3 AuthenticationFailureReport (AFREPORT) ............................................62


15.1.5 AuthenticationStatusReport (ASREPORT) ............................... .............62

15.1.6 BaseStationChallenge (BSCHALL) ........................................................62

CDG #138, Rev 0.34 December 5, 2010 iv

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

4


7/81


15.1.7 CountRequest (COUNTREQ) ................................................................63

15.1.8 RandomVariableRequest (RANDREQ) ..................................................63

15.1.9 SMSDeliveryPointToPoint (SMDPP) ............................................... ..... ..63

15.2 TIA-41-E new relevant operations ................................................................ ........63

15.2.1 OTASPRequest (OTASPREQ) ......................................................... .....63

15.3 TIA-41-E updates to existing relevant parameters ................................................64

15.3.1 ActionCode (ACTCODE) ........................................................................64

15.3.2 SystemCapabilities (SYSCAP) ............................................................. ..64

15.4 TIA-41-E new relevant parameters .......................................................................65

15.4.1 AKeyProtocolVersion (AKEYPV) ............................................................65

15.4.2 AuthenticationResponseReauthentication (AUTHRA) ................... ........65

15.4.3 BaseStationPartialKey (BSKEY) ............................................................65

15.4.4 MobileStationPartialKey (MSKEY) .........................................................6515.4.5 OTASP_ResultCode (OTASPRC) ..........................................................65

15.4.6 RandomVariableReauthentication (RANDRA) .......................................65

15.4.7 ReauthenticationReport (RARPT) ..........................................................65

15.4.8 SuspiciousAccess (SUSACC) ........................................................... .....66

16. TIA-945 Authentication Reference ..............................................................................67

16.1 TIA-945 updates to existing authentication operations .........................................67


16.1.2 RegistrationNotification (REGNOT) ........................................................67

16.2 TIA-945 new authentication operations ........................................................... .....67

16.2.1 AKADirective (AKADIR) ...................................................................... ...67

16.2.2 AKARequest (AKAREQ) ..................................................................... ...67

16.2.3 AKAStatusReport (AKAREPORT) ..........................................................68

16.3 TIA-945 updates to existing authentication parameters ........................................68

16.3.1 AuthenticationCapability (AUTHCAP) ............................................... .....68

16.3.2 SystemCapabilities (SYSCAP) ............................................................. ..68

16.4 IS-945 new authentication parameters .................................................................68

16.4.1 AKA_AuthenticationVector (AKAV) ...................................................... ..68

16.4.2 AKA_AuthenticationVectorList (AKAVL) ......................................... .......69

16.4.3 AKA_Keys (AKAK) ............................................................................ .....69

16.4.4 AKA_Report...........................................................................................69

16.4.5 AKA_VectorCount..................................................................................69

16.4.6 AUTS .................................................................................................. ...69

16.4.7 RANDA ........................................................................................... .......69

CDG #138, Rev 0.34 December 5, 2010 v

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

4


8/81


CDG #138, Rev 0.34 December 5, 2010 vi

1

2

3

1

4


9/81


Figures

CDG #138, Rev 0.34 December 5, 2010 vii

1

2

3

1

4


10/81


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-4: Retrieval of pre-programmed A-keys from manufacturers..................... .....10

Figure 3-5: Provisioning the AC ........................................................................................11

Figure 3-6: A-key programmed by manufacturer.............................................................12

Figure 3-7: A-key programmed using secure device at retailer.................................... ..12

Figure 3-8: A-key obtained by contacting customer care................................................13

Figure 4-9: Home versus local authentication..................................................................14

Figure 4-10: Authentication by home system...................................................................14

Figure 4-11: Local authentication......................................................................................15

Figure 5-12: Global challenge to MS..................................................................................18

Figure 5-13: Generation of AUTHR for global challenge............................................ .....19Figure 5-14: Global challenge message flow when SSD is not shared..........................19

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

Figure 5-16: COUNT update process.................................................................................21

Figure 5-17: Authentication reporting for unique challenges.........................................22

Figure 6-18: Unique challenge to MS.................................................................................23

Figure 6-19: Generation of AUTHU for unique challenge................................................23

Figure 6-20: Unique challenge initiated by roamers home system................................24

Figure 6-21: Unique challenge initiated by visited system..............................................25

Figure 6-22: Authentication reporting for unique challenges.........................................26

Figure 7-23: SSD update process when SSD is shared...................................................28

Figure 7-24: SSD update process when SSD is not shared.................................. ..........29

Figure 8-25: Handling of suspicious access attempts.....................................................31

Figure 9-26: OTASP attachment between MSC and OTAF............................................ ..33

Figure 9-27: OTASP A-key generation procedure............................................................35

Figure 9-28: A-key generation call flow.............................................................................35

Figure 9-29: OTAF-initiated SSD update procedure.........................................................36

Figure 11-30: Information contained in an authentication vector...................................42

Figure 11-31: Simplified conceptual flow of AKA authentication...................................43

Figure 11-32: Distribution of AVs to the visited system..................................................45

Figure 11-33: Generation of AK for AKA...........................................................................46

Figure 11-34: AKA synchronization failure (i.e. SQN mismatch).......................... ..........47

Figure 11-35: Generation of (X)MAC_A for AKA...............................................................48

Figure 11-36: AKA rejection by the MS (i.e. MAC_A mismatch)......................................48

CDG #138, Rev 0.34 December 5, 2010 viii

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

4


11/81


Figure 11-37: Generation of (X)RES for AKA....................................................................49

Figure 11-38: AKA response failure (i.e. RES mismatch)............................................. ...50

CDG #138, Rev 0.34 December 5, 2010 ix

1

2

3

1

2

3

4


12/81


Tables

1-1: Evolution of CDMA authentication...............................................................................2

4-2: Messages that may be used to enable or disable local authentication...................16

5-3: Authentication parameters provided by MS when global challenges are required..............................................................................................................................................18

5-4: Messages that may contain UpdateCount to initiate COUNT update process...... .22

7-5: Messages that may contain RANDSSD to initiate SSD update process.................27

8-6: Authentication enhancements in IS-778....................................................................30

9-7: New action codes defined in TIA-41-E.......................................................................34

CDG #138, Rev 0.34 December 5, 2010 x

1

2

3

1

2

3

4

5

6

7

8

9

10

4


13/81

CDMA Authentication Terminology

1. Introduction

This paper specifically focuses on the security concept of authentication. While written from

the perspective of roaming, the authentication information presented herein should be useful

for any carrier interested in implementing or updating authentication support.

Both 2nd generation authentication based on Cellular Authentication and Voice Encryption

(CAVE) and 3rd generation authentication based on Authentication and Key Agreement

(AKA) are addressed in this paper. In the context of CAVE, the term authentication refers to

primarily unilateral1 mechanisms that allow the network to validate the authenticity of the

roaming mobile station (MS). In the context of AKA, these mechanisms are bilateral and

support both network validation of MS authenticity and MS validation of network authenticity.

Additional security concepts such as encryption, data integrity, and security associations

may be mentioned but are considered to be outside the scope of this paper.

While this paper addresses both CAVE- and AKA-based authentication, the larger focus is

on CAVE. The reasoning for this choice of focus is to provide carriers with information,

insight, and recommendations on the authentication mechanisms currently being deployed.

CAVE continues to be deployed and will likely continue to be the most prevalent form of

authentication for the next several years while the industry migrates to AKA. During this

migration, interoperability will necessitate that AKA deployment be done in conjunction with

support for CAVE rather than as a complete replacement.

The discussion of CAVE-based authentication begins with an overview of authentication

issues and concepts, an introduction to A-key considerations, and an explanation of the

mechanisms employed by CAVE as defined in TIA-41-D. Following this, TIA-41-E

authentication enhancements and Over-The-Air (OTA) support are discussed. Finally,

practical recommendations are provided.

Information on CAVE is followed by an exploration of AKA-based authentication. AKA

concepts and details are presented in sufficient detail to allow carriers unfamiliar with AKA to

thoroughly understand AKA authentication mechanisms.

As may or may not be apparent, this progression of information maps roughly to the

evolution of CDMA authentication beginning with the introduction of network support for

CAVE-based authentication in TSB51 to the introduction of network support for AKA in TIA-

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 allowthe MS to validate the authenticity of the network using a base station challenge, once SSD has beenupdated, CAVE-based authentication is unilateral (i.e. the network always authenticates the MS).

CDG #138, Rev 0.34 December 5, 2010 1

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

4

5

6

7


14/81


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-778incorporated

Oct. 2005 TIA-945 MAP support of Authentication and Key Agreement

(AKA) alternative to CAVE-based authentication

Reference sections containing various authentication operations, parameters, and fields

discussed throughout the paper are provided at the end of the paper. These sections are

separated into TIA-41-D, TIA-41-E, and TIA-945. References and modifications to existing

items are highlighted to allow the reader to understand when various items were introduced

and modified. These sections are not intended as a proxy to the standards documents for

the purposes of implementation. Rather, the inclusion of these sections is an attempt toreduce reader frustration as often times being able to quickly reference additional

information such as which field values are supported by a particular parameter can clarify

uncertainty regarding its use or purpose.

CDG #138, Rev 0.34 December 5, 2010 2

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

4


15/81


2. Authentication Overview

2.1 What is cloning fraud

A cloned mobile station or clone is simply a Mobile Station (MS) that has been

programmed with illegally obtained Equipment Serial Number (ESN) and Mobile Station

Identity (MSID) information. Because these ESN and MSID values are sent unencrypted

over the air interface by the MS to identify itself to the network, it is possible for a fraudster to

intercept them. However, it may also be possible for fraudsters to obtain these values from

the MS if they are able to access programming mode or work with employees of a carrier to

steal them.

Figure 2-1: Susceptibility of MS identity information

In any event, once these values have been obtained by a fraudster, they can be

programmed into other mobile stations to create clones. The use of clones to fraudulently

access a carrier network is known as cloning fraud and is the most prevalent form of

technical fraud in CDMA networks.

While this may seem very complex for the average criminal to attempt, tools to assist in the

creation of clones are only an Internet search away. For example, for a few hundreds

dollars, a fraudster can readily purchase software and universal handset programming

equipment that allows them to reprogram a mobile station with new values for ESN, MSID,

A-key, etc In the past, such equipment was only available to carriers for troubleshooting

purposes and cost thousands of dollars.

2.2 Why is authentication important

Cloning fraud has several costs. First, carriers incur lost revenue potential in the form of not

being compensated for fraudulent use. Next, customer care resources must be expended to

work with legitimate subscribers that have been cloned in order to resolve billing issues and

reprogram mobile stations. Finally, potential switching and intangible costs are associated

with lower customer satisfaction when these legitimate subscribers discover fraudulent

charges on their bills. In short, the result of cloning fraud is that carriers lose money and

legitimate subscribers are unhappy.

When a mobile station is cloned and used to fraudulently access the network of a roaming

partner, this situation is exacerbated. In the roaming scenario, not only does the home

CDG #138, Rev 0.34 December 5, 2010 3

ESN, MSID

MS identifies itself tothe network by sendingits ESN and MSIDvalues unencryptedover the air interface.

1

2

3

1

2

3

4

5

6

7

8

910

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

4


16/81


network incur the aforementioned costs, but it must also pay the roaming partner for the

intercarrier roaming charges resulting from the fraudulent access. This translates into real

monetary costs that directly affect the home networks bottom line.

Authentication protects carrier networks from fraudulent access by cloned mobile stations.

The mechanisms used by CAVE-based authentication ensure that a mobile station possess

valid shared secret data before allowing it to access the network. These mechanisms

protect both carriers and legitimate subscribers from the negative effects of cloning fraud.

2.3 How effective is authentication

The following subsections discuss the effectiveness of authentication in various technical

fraud scenarios. However, it should be noted that how effective an authentication

implementation is depends largely on policy decisions made by the home and visited

network. These policy decisions can make the difference between an effective and a

frustratingly ineffective implementation. For example:

Is A-key information sufficiently protected?

Is authentication used in both roaming and non-roaming scenarios?

Are unique challenges used?

Is the Call History Count (COUNT) mechanism effectively used?

Are global challenge values frequently changed?

2.3.1 Regular clones

CAVE-based authentication is completely effective against regular cloning fraud. Any

attempt by a regular clone to access a network using authentication should be unsuccessful.

The reason is that, while the regular clone can identify itself as another subscriber usingillegally obtained ESN and MSID information, it will not possess valid shared secret data

required to successfully pass an authentication challenge. Therefore, authentication will

completely solve the majority of cloning fraud.

2.3.2 Complete clones

A less likely but more problematic scenario is the existence of a complete clone. A

complete clone is one that contains a correct A-key. Complete clones are more problematic

because they are able to successful complete SSD update procedures and authentication

challenges.

The existence of a complete clone indicates a problem with a carriers security procedures

that has allowed A-key information to be compromised. Nonetheless, as will be discussed

later in this paper, CAVE-based authentication provides a Call History Count (COUNT)

mechanism to help identify the existence of clones, even in the case of a complete clone.

Once identified, service may be denied, though this action will require the legitimate

subscriber to contact customer care to re-activate their service.

CDG #138, Rev 0.34 December 5, 2010 4

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

4


17/81


2.3.3 Replay attacks

A replay attack is a special scenario in which a fraudster intercepts the entire contents of a

legitimate roamers message and replays this information from a clone. Because the

intercepted message contained a correct global challenge response required to successfully

complete authentication, the replayed message will also successfully completeauthentication if the challenge value is the same. Therefore, replay attacks are inherently

limited by how frequently the visited network changes the global challenge value sent to all

mobile stations attempting to access the network.

2.4 Authentication concepts

2.4.1 Cellular Authentication and Voice Encryption (CAVE)

Cellular Authentication and Voice Encryption (CAVE) is a set of cryptographic2 algorithms

collectively referred to as the CAVE algorithm which are used during the authentication

process. Based on the inputs used, the CAVE algorithm enables calculation of SSD duringthe SSD Update procedure and authentication signatures during challenge/response

procedures. The CAVE algorithm is also used to calculate various values used during

optional encryption and voice privacy procedures which are not discussed in this document.

The CAVE algorithm used in CDMA is standardized and procedures are defined to ensure

that both the network and the MS are using the same version of CAVE algorithm during

authentication. If the MS is equipped with a removable user identity module (R-UIM), the

CAVE algorithm will reside on this R-UIM and all authentication calculations using the CAVE

algorithm will be performed by the R-UIM. Otherwise, the MS will perform these

calculations.

2.4.2 Authentication Key (A-key)

Also known as the master key, the A-key is the cornerstone of CAVE-based authentication.

The A-key is provisioned in the home Authentication Center (AC) and the mobile station

(MS). If the MS uses an R-UIM, the A-key is stored on this R-UIM; otherwise, the A-key is

stored in semi-permanent memory on the MS. In either case, users should not be able to

access or view the A-key on their MS. Once provisioned, an A-key is generally only

changed if the home operator suspects that it has been compromised.

The purpose of the A-key in authentication is to generate Shared Secret Data (SSD),

specifically an SSD_A secondary key. It is this SSD, not the A-key, that is used during the

authentication process. This helps protect the A-key from being compromised. While SSD

may be shared with a partner network to enable local authentication, the A-key, onceprovisioned, is never shared outside of the MS and home AC.

2 Useless knowledge for your next dinner party: cryptography comes from the Greek words kryptosand graphein, which together mean hidden writing.

CDG #138, Rev 0.34 December 5, 2010 5

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

4

5

6


18/81


2.4.3 Shared Secret Data (SSD)

Shared Secret Data (SSD) is a 128-bit value that is calculated using the CAVE algorithm

with the A-key as an input. This calculation occurs during a procedure called SSD Update.

During the SSD Update procedure, both the Authentication Center (AC) and the Mobile

Station (MS) separately calculate SSD. It is this SSD, not the A-key that is used duringauthentication.

Note that the term Shared Secret Data refers to the fact that the secret data is shared

between the network and the MS. This SSD may or may not also be shared between home

and roaming partner networks. If the home network chooses not to share SSD with their

roaming partner network, it is still shared between home network and MS. If the home

network does share SSD with their roaming partner network, it is referred to as Shared

SSD because the SSD shared between home network and MS is also shared with the

partner network.

As shown below, the 128-bit SSD actually consists of two 64-bit keys: SSD_A and SSD_B.

The SSD_A key is the one used during authentication to calculate authentication signatures.When authentication documents refer to SSD during the authentication process, they are

generally referring to SSD_A. The SSD_B key is not detailed in this document as its

purpose is to enable the generation of session keys that are used during optional encryption

and voice privacy procedures.

CDG #138, Rev 0.34 December 5, 2010 6

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

4


19/81


A-Key

SSD_A SSD_B

SSD is a 128-bit value

that actually consists

of two 64-bit keys:

SSD_A and SSD _B

CAVE algorithm

ESN RAND_SSD

SSD_A is used

during authenticationto generate response

signatures

SSD_B is used togenerate sessionkeys that enable

voice privacy and

encryption

64-bit

64-bit 64-bit

Figure 2-2: Shared Secret Data (SSD)

Use of the SSD rather than the A-key during authentication helps to protect the A-key from

being compromised since SSD may be shared with a roaming partner network but the A-key

is never shared. In addition, sharing SSD allows partner networks to locally perform

authentication rather than requiring all partner networks to proxy authentication signaling

back to the home HLR/AC. As a home network scales its roaming business with additional

partner networks, sharing of SSD becomes increasingly important for reducing signaling

costs and preventing the HLR/AC from becoming a bottleneck.

2.4.4 Challenge/Response mechanism

Authentication is based on a challenge/response mechanism. This mechanism involves the

serving network challenging the MS with a randomly generated value. The MS uses this

challenge value along with its SSD and other information such as its ESN as inputs into the

CAVE algorithm to generate an authentication signature.

As shown below, this authentication signature is sent by the MS as a response to thenetworks challenge. As this document focuses on authentication in the context of roaming,

the scenario shown below is that of a roamer being authenticated by a visited network .

However, the mechanism is conceptually the same for a non-roaming scenario.

CDG #138, Rev 0.34 December 5, 2010 7

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

4


20/81


Figure 2-3: Challenge/Response Mechanism

If SSD has been shared with the serving network, the MSC/VLR performs the same

calculation. If the SSD has not been shared, the MSC/VLR proxies the authentication

signature from the MS to the home HLR/AC where this calculation will be performed. In

either case, the authentication signature calculated by the network (i.e. HLR/AC or

MSC/VLR) is compared to the one calculated by the MS to determine whether the MS is

authentic.

This mechanism works because, in order for the calculated values to match, the SSD input

that was used by the network during its calculation must be the same as the SSD input that

was used by the MS. Essentially, authentication provides the network with a way to ensure

that the MS possesses correct SSD.

2.5 Elements involved in authentication

2.5.1 A-key Management System (AKMS)

The A-key Management System (AKMS) refers to the system by which a carrier securely

manages A-key values. This typically involves secure retrieval, random generation, storage,

and distribution of A-key values. The purpose of the AKMS is to ensure that A-key values

remain secure while enabling them to be provisioned into both the HLR/AC and MS. Ideally,

the AKMS is a dedicated, secure element maintained by the carrier; however, in practice, it

may simply be a set of procedures for ensuring the security of A-key information.

2.5.2 Authentication Center (AC)

Often collocated with the Home Location Register (HLR) and referred to as the HLR/AC, the

Authentication Center (AC) is where A-key information for each subscriber is stored. When

a new subscriber is activated, the A-key value provisioned in the MS must also be

provisioned in the AC.

CDG #138, Rev 0.34 December 5, 2010 8

Home Network

HLR/AC

MSC/VLR

Visited Network

SSD

SSD

SSD Challenge (Challenge Value)

Response (Auth Signature)

A-key

A-key

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

4


21/81


The AC controls authentication processes and policies such as the following:

Initiation of SSD update procedures

Initiation/revocation of SSD sharing

Calculation of global challenge authentication signatures when SSD is not shared

Initiation of unique challenges

Calculation of unique challenge authentication signatures

Comparison of network and MS authentication signatures when SSD is not shared

Initiation of Call History Count updates

How to respond to authentication failures

2.5.3 Visitor Location Register (VLR)

Often collocated with the Mobile Switching Center (MSC) and referred to as the MSC/VLR,

the Visitor Location Register (VLR) interacts with the roaming MS during authentication. IfSSD is not shared, the MSC/VLR simply proxies authentication signaling between the

HLR/AC and the MS. However, the more common scenario is for SSD to be shared.

When SSD is shared, the MSC/VLR locally performs authentication signature calculation

and comparison. This approach both reduces signaling between home and visited networks

and offloads authentication processing that would otherwise be performed by the HLR/AC.

2.5.4 Mobile Station (MS)

The A-key value provisioned in an activated Mobile Station (MS) will match the A-key value

provisioned in the home HLR/AC associated with that subscriber. To participate in

authentication procedures, the MS must have the CAVE algorithm and be capable of using

this algorithm to generate new SSD during SSD update procedures and authentication

signatures during challenge/response procedures.

Basically, all new CDMA handsets are authentication capable. Many new handsets also

support removable user identity modules (R-UIM). If the MS uses an R-UIM, the CAVE

algorithm will reside on this R-UIM and all authentication calculations using CAVE will be

performed by the R-UIM. Otherwise, the MS will perform these calculations.

CDG #138, Rev 0.34 December 5, 2010 9

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

4


22/81


3. Managing and Provisioning A-keys

The management and provisioning of A-key values is controlled by an element known as the

A-Key Management System (AKMS). This element provides for secure retrieval, random

generation, storage, and distribution of A-key values. The AKMS ensures that A-key values

remain secure and supports the provisioning of these values into both the MS and AC.

3.1 A-key generation

3.1.1 A-key generated by manufacturer

The most common method of programming A-keys into mobile stations is for the A-key value

to be generated by the manufacturer and pre-programmed into the MS at the factory. When

this method is used, the manufacturer must also provide the ESN/A-key information to the

carrier for storage in the AKMS as illustrated below. Before activating a pre-programmed

MS, the AKMS must provision the ESN and A-key associated with the MS into the AC.

Figure 3-4: Retrieval of pre-programmed A-keys from manufacturers

To ensure the secure transport of ESN/A-key data between manufacturer and carrier, two

approaches are commonly used. The first, and most robust, approach involves the use of

an Electronic Data Interchange (EDI) between the manufacturers database subsystem and

the carriers AKMS. This approach allows the AKMS to directly retrieve A-key information

from a manufacturers database subsystem with no risk of exposing the information toanyone within the carrier organization. However, while this solution works very well, smaller

carriers often do not have access to an EDI infrastructure.

The second, and more widely used, approach involves the manufacturer providing the

carrier with an encrypted file containing the list of ESN/A-key pairs. The carrier then typically

uses a script to automatically decrypt and upload this information into the AKMS. This

method is somewhat less secure than the EDI infrastructure approach since a person with

CDG #138, Rev 0.34 December 5, 2010 10

ManufacturersCarrier

ESN / A-keyinformation

AKMS

ManufacturerAAA

ManufacturerBBB

ManufacturerCCC

Secure EDI orencrypted file

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

4


23/81


access to the script could potentially decrypt and access the contents of the file. However,

many carriers find this approach to be an equitable tradeoff between security and cost-

effectiveness.

3.1.2 A-key generated by carrierThe carriers AKMS typically provides for the secure generation of random A-key values. In

addition to supporting activation of mobile stations without pre-programmed A-key values,

this capability provides the flexibility to re-program legitimate mobile stations with new A-key

values in cases where fraud has been detected.

Practices such as using all zero default A-key values are not recommended since they allow

the A-key to be easily guessed by fraudsters, thereby compromising the effectiveness of

authentication. Whether provisioned by the manufacturer or AKMS, A-keys should always

be securely and randomly generated and protected from being viewed to the greatest extent

practicable.

3.2 A-key provisioning

3.2.1 Provisioning the AC

A-keys may either be generated by the MS manufacturer and provided to the carrier for

storage in the AKMS or generated by the AKMS itself. In either case, in order for service to

be activated, an A-key value must be provisioned into the AC as illustrated below.

Figure 3-5: Provisioning the AC

Since both the AKMS and AC reside within the carriers network, the mechanism by which

the AKMS provides MIN/ESN/A-key information to the AC is an internal issue. However,

because the A-key is involved, the transfer of information between these entities should be

secure and protected from being viewed to the greatest extent practicable. Wherever

possible, it is recommended that automated methods of retrieving the A-key from the AKMS

and provisioning it into the AC during activation be used.

Some implementations involve A-key values being internally generated by the AC. In such

cases, the AKMS function is essentially incorporated into the AC and there is no transfer of

A-key information between AKMS and AC entities.

CDG #138, Rev 0.34 December 5, 2010 11

AC

A-keyA-key

AKMS

Secureprovisioning orOTASP A-key

generation

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

4


24/81


3.2.2 Provisioning the MS

Provisioning of the MS may be implemented in several ways. The following subsections

discuss various methods that are available to carriers to facilitate the provisioning of A-key

values into mobile stations.

3.2.2.1 A-key programmed by manufacturer

As previously mentioned, pre-programming of A-keys into mobiles stations by the

manufacturer is the most common method currently in use. When this method is used, the

manufacturer will also provide the pre-programmed A-keys to the carriers AKMS where they

are stored until needed for service activation. This scenario is illustrated below.

Figure 3-6: A-key programmed by manufacturer

Pre-programmed A-keys are not mutually exclusive with the use of other methods discussed

herein to program an A-key into an MS. In other words, the fact that an MS has been pre-

programmed with an A-key value by the manufacturer does not prevent the carrier from

generating and programming a new A-key value into the MS if needed or preferred.

3.2.2.2 A-key programmed at the retailer

Another option for provisioning the MS is to allow it to occur at the point of sale, i.e. at the

retailer. The secure approach to enabling retailer provisioning of mobile stations is for the

retailer to utilize an MS programming device (e.g. Synacom Validator) that communicates

directly with the carriers AKMS to retrieve A-keys as illustrated below.

Figure 3-7: A-key programmed using secure device at retailer

Encryption on the communications link between the programming device and the AKMS

allows the A-key to be securely retrieved from the AKMS and protected from view by the

CDG #138, Rev 0.34 December 5, 2010 12

AC

A-key

A-key

A-key

AKMS

Manufacturer

database

AC

A-keyA-keyA-key

AKMS

Secure MSprogrammingdevice

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

4


25/81


retailer. This approach also removes the potential for human error in entering the A-key by

allowing the programming device to retrieve the A-key and program it directly into the MS.

3.2.2.3 A-key programmed using OTASP A-key generation procedure

Perhaps the most flexible option for programming the A-key into the MS is the use of Over-

The-Air Service Provisioning (OTASP). MAP support for OTASP was introduced in IS-725

with support for Over-The-Air Parameter Administration (OTAPA) added in IS-725-A.

OTASP/OTAPA support in IS-725-A was later incorporated into TIA-41-E. For more

information, see the9 Over-The-Air (OTA) Support section of this paper.

3.2.2.4 A-key obtained by contacting customer care

This final approach involves a subscriber, retailer, or technician calling the carriers customer

care center from a working phone to obtain the A-key. Once the caller has been determined

to be legitimate, customer care requests a new A-key value from the AKMS. The AKMS

securely and randomly generates the new A-key value and provides this value to both

customer care and the AC. Customer care may then provide the A-key value to the caller for

manual entry into the MS. This approach is illustrated below.

Figure 3-8: A-key obtained by contacting customer care

Because the previously discussed alternatives for programming the A-key into the MS

provide greater security and less user interaction, this approach is more often used for

troubleshooting than new service activation. However, if carriers do choose to use this

approach for new service activation, it is recommended that they also have fraud detection

systems in place to detect excessive SSD updates that would occur when legitimate A-keys

are being programmed into cloned mobile stations.

CDG #138, Rev 0.34 December 5, 2010 13

AC

A-key

A-key

A-key

AKMS

A-key

CustomerCare

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

4


26/81


4. Home versus local authentication

Authentication of a roaming MS may be

performed by the roamers home system

or locally by the system to which the MS

is attempting to gain access. However,

roaming partners most commonly

choose to support local authentication

because of its advantages in reducing

signaling between visited and home

systems. The two primary requirements

for supporting local authentication

include: (1) the ability of the visited VLR

to support CAVE algorithms for localcalculation of authentication signatures

and (2) the willingness of the home

system to share SSD with the visited

VLR to enable these calculations.

Visited

supports local

auth

YES

AC

shares SSDwith visited

VLR

NO

NO

YES

Homeauthentication

Localauthentication

Auth required

Figure 4-9: Home versus local

authentication

As illustrated to the right, if either of the two requirements are not met, authentication must

be performed by the home system. The visited system can inform the home system of its

ability to support local authentication using the TIA-41 SystemCapabilities (SYSCAP)

parameter.

4.1 Authentication by home system

To support home system based authentication, parameters and authentication signatures

must be relayed between the visited and home systems using TIA-41 messages. The figure

below illustrates the path of signaling when the roamers home system performs

authentication.

Figure 4-10: Authentication by home system

CDG #138, Rev 0.34 December 5, 2010 14

SS7VLR

MSCHLR

AC

Visited System Home System

SSD

COUNT

A-keyA-key

SSD

COUNT

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

4


27/81


While home system based authentication works, it is not efficient. In the case of global

challenges which are often performed on every system access attempt (e.g. registration,

origination, termination, data burst, etc), home system based authentication results in a

large amount of unnecessary SS7 signaling traffic between home and visited systems and

burdens the home AC with generating the authentication signature for each challengeattempt. Of particular concern is the increased signaling traffic inherent in this approach

because it directly results in additional costs to carriers and call delays to roamers.

4.2 Local authentication by visited system

The more common approach to

authenticating roamers in a visited system

involves the home AC sharing SSD with a

visited VLR so that authentication may be

performed locally. Once SSD has been

shared with the visited VLR, authenticationmay be performed by the visited system

without involving the home system.

Illustrated to the right, this approach

distributes authentication closer to the

roamer while disburdening the home AC and

reducing network signaling and call delays.

Figure 4-11: Local authentication

Authentication signaling between the home and visited systems occurs during the initial

system access attempt (i.e. registration) before SSD and COUNT have been shared to

enable local authentication. However, once enabled, subsequent authentication attempts

are performed locally as illustrated in the above figure for the duration of time that the

roaming MS is registered in the visited network.

Note that the home system is not shown in the above figure since, once SSD has been

shared, local authentication does not require involvement from the home system. However,

in the event that a roaming MS were to fail local authentication, the visited system would

provide the home system with an authentication failure report (i.e. AFREPORT message).

4.3 SystemCapabilities (SYSCAP) of visited system

In order for a visited system to support local authentication, the VLR in this system must be

capable of supporting the CAVE algorithm and sharing SSD. These capabilities allow the

visited system to locally generate authentication signatures to compare against ones

received from the MS. The capability of the visited system to support the CAVE algorithm

and share SSD are indicated to a roamers home system via the SystemCapabilities

(SYSCAP) parameter.

SYSCAP is a required parameter in the AuthenticationRequest (AUTHREQ) message sent

from the visited network to the roamers home network. Therefore, when a roaming MS first

CDG #138, Rev 0.34 December 5, 2010 15

VLRMSC

Visited System

A-key

SSDCOUNT

SSDCOUNT

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

4


28/81


attempts to access a visited system with global challenges enabled, the home system is

notified of the system capabilities of the visited system via the AUTHREQ. If SYSCAP

indicates that the visited network is capable of local authentication, the home system may

enable SSD sharing by including SSD in the AUTHREQ response message (authreq) to

allow subsequent system access attempts by the roaming MS in this visited system to beauthenticated locally.

SYSCAP is also a required parameter in authentication report messages (i.e. ASREPORT or

AFREPORT) sent from the visited system to the home system to indicate the result of an

authentication attempt. If SYSCAP indicates that the visited network is capable of local

authentication, the home system may enable SSD sharing by including SSD in the

authentication report response message (i.e. asreport or afreport) to allow subsequent

authentication challenges to the roaming MS in this visited system to be performed locally.

4.4 Enabling and disabling local authentication

The home system enables local authentication by sharing SSD with the visited VLR. Note

that while SSD is shared by the home system, the A-key is not. This approach protects the

A-key since it is never transmitted to the visited network and provides an extra layer of

security since the home system may initiate an SSD update process at any time if SSD is

believed to have been compromised.

Local authentication may be enabled or disabled (i.e. sharing of SSD information invoked or

revoked with the visited VLR) using any one of the following messages sent from the home

system to the visited system. Note that this occurs independently for each roaming MS, not

for the entire visited system.

4-2: 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

To enable local authentication (i.e. invoke sharing of SSD), the home system includes an

SSD parameter in one of the above messages sent to the visited system. If the

CallHistoryCount (COUNT) mismatch mechanism is being used for clone detection, aCOUNT parameter will also be included so that both SSD and COUNT are shared with the

visited system.

To disable local authentication (i.e. revoke sharing of SSD), the home system includes the

SSDNotShared (NOSSD) parameter in one of the above messages sent to the visited

system. If the COUNT mismatch mechanism is being used, COUNT will also have been

shared. Because the home system needs to retrieve this COUNT value from the visited

CDG #138, Rev 0.34 December 5, 2010 16

1

2

3

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

4


29/81


system, the AUTHDIR message is typically used to turn off SSD (and COUNT) sharing. Use

of AUTHDIR to revoke sharing is simply more efficient because COUNT may be included in

the AUTHDIR Return Response (authdir) from the visited network. Since there is no

response to authdir, asreport, or afreport return response messages, use of these messages

to turn off sharing would require an additional message transaction involving aCountRequest (COUNTREQ) from home to visited system and COUNTREQ Return

Response (countreq) from visited to home system to retrieve the COUNT value.

CDG #138, Rev 0.34 December 5, 2010 17

1

2

3

1

2

3

4

5

6

7

4


30/81

5. Global Challenges

Global challenges are used by systems to

ensure that all mobile stations attempting to

access the system are authenticated.

Mobile stations that roam into visited

systems with global challenge enabled are

requested to provide authentication

parameters. The visited system indicates

this request by setting the authentication bit

(i.e. AUTH=1) in the overhead message

train (OMT). The OMT should also include

the global random challenge value (RAND)

to be used in generating the authenticationresult.

Figure 5-12: Global challenge to MS

In response to the global challenge indicated by AUTH=1, authentication-capable mobile

stations will include the following authentication parameters in system access messages to

allow themselves to be authenticated in the visited network.

5-3: 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 AUTHRCOUNT Current call history count stored in the MS (6-bit value)

All system access attempts from the mobile will require these parameters to be included

when AUTH=1. System access attempts may include registration, origination, termination

(i.e. page response or reconnect), and data burst (e.g. SMS) messages.

5.1 Authentication signature (AUTHR)

The basis for authentication is the ability for both the MS and the authentication controller

(i.e. visited VLR if SSD is shared or home AC if not) to generate authentication signatures

that may be compared. In the case of a global challenge, the authentication signature isreferred to as the authentication result (AUTHR) and is calculated using the Cellular

Authentication and Voice Encryption (CAVE) algorithm with inputs illustrated below.

VisitedSystem

overhead message trainAUTH=1, RAND

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

2


31/81

Figure 5-13: Generation of AUTHR for global challenge

The MS generates and includes an AUTHR value in all system access messages in thevisited network. Upon receiving the AUTHR from the MS, the visited system may proceed

with authentication locally or forward this AUTHR value to the roamers home network for

authentication. Whether MS response to the global challenge is authenticated by the visited

system or the roamers home system depends on whether SSD is shared with the visited

VLR.

5.2 Roamer authenticated by its home system

If SSD is not shared with the visited system, the AUTHR value returned by the MS and the

RAND value used by the MS to generate this AUTHR must be forwarded to the roamers

home system for authentication. The global challenge message flow is illustrated below for

the case in which SSD information is not shared with the visited VLR.

Figure 5-14: Global challenge message flow when SSD is not shared

Random Challenge (32-bit)32-bit RAND received in OMT. If noRAND was received, default is zero.

ESN (32-bit)ESN provisioned in MS

Authentication Data(24-bit)If origination, use the last 6 dialeddigits. Otherwise, use IMSI_S1(i.e. last 6 digits of MIN)

Secret Data (64-bit)SSD_A part of SSD generated usingCAVE and provisioned A-key

CAVEalgorithm

AUTHR (18-bit)Authentication

Signature

VisitedSystem

HomeHLR/AC


system accessAUTHR, RANDC, COUNT

AUTHREQAUTHR, RAND, COUNT

authreq

SSDSSD

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

2


32/81

Note that the RAND, not the RANDC, is forwarded to the home system. The RAND value,

which was selected by the visited system, was used by the MS to generate an AUTHR value

in response to the global challenge. Since the AC will need to use this same RAND to

generate an AUTHR value to compare to the one received from the MS, the RAND is

included in the AUTHREQ message sent to the home system.

5.3 Roamer authenticated locally by the visited system

If SSD is shared with the visited VLR, forwarding RAND and AUTHR information to the

roamers home system for authentication is unnecessary. Because the visited system has

the SSD required to generate an AUTHR value locally to compare to the one received from

the MS, authentication can be performed by the visited system without involving the

roamers home system.

A global challenge message flow is illustrated below for the case in which SSD information is

shared with the visited VLR.

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

5.4 Pre-validation using RANDC

The RANDC consists of the 8 most significant bits of the RAND and is used by the base

station to pre-validate the system access message sent by the MS. The base station

compares the RANDC received from the MS to the 8 most significant bits of the active

RAND being broadcast on the OMT. While a system may discard a system access

message if a mismatch is detected, the mismatch does not necessarily indicate that the MS

attempting to access the system is fraudulent, only that a cloned MS scenario may exist.

For example, a mismatch could occur when an MS in a border area uses a RAND value

being transmitted by a neighboring system or when an MS fails to receive the RAND value

being transmitted and uses a default value (i.e. RAND = 0).

VisitedSystem


system accessAUTHR, RANDC, COUNT

SSDSSD

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

2


33/81

5.5 Clone detection using COUNT

CallHistoryCount (COUNT) is a counter value maintained by the roaming MS, home AC,

and, if local authentication is enabled, the visited VLR. Used during the global authentication

process, this counter provides a mechanism for detecting cloned mobile stations, especiallywhen SSD and/or A-key values have been compromised.

When a system access message is received in the visited system, the COUNT value

provided by the roaming MS is compared with the one maintained by the authentication

controller to determine whether they are consistent. A mismatch suggests that a clone may

exist but is not necessarily a conclusive indication of cloning since RF transmission issues

may result in occasional minor mismatches. However, there should not be a large delta

between these values.

The policies of the authentication controller will determine whether to allow access, issue a

unique challenge, or deny access based on a COUNT mismatch. However, cases of largediscrepancies or repeated mismatches should be treated as indications of cloning fraud.

5.5.1 Updating CallHistoryCount (COUNT)

COUNT is updated (i.e. incremented) by the home AC according to an internal algorithm.

This algorithm typically updates the value at irregular intervals rather than simply

incrementing it with each call. To initiate an update, the AC sends an TIA-41 UpdateCount

parameter to the visited system as illustrated below.

Figure 5-16: COUNT update process

Similar to the RANDSSD parameter used to initiated the SSD update procedure, the

UpdateCount parameter may be included by the home AC in any of the following messages

sent to the visited system to initiated the COUNT update procedure:

VisitedSystem HomeHLR/AC

parameter update

AUTHDIRUpdateCount

authdirCOUNT

parameter update confirm

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

2


34/81

5-4: 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

5.6 Reporting of results to roamers home system

If SSD is shared with the visited network and the MS fails the global challenge, an

AuthenticationFailureReport Invoke (AFREPORT) message will be sent by the visited

system to inform the roamers home system of the failure as illustrated below. Reports of

successful global challenges in the visited network are unnecessary. Likewise, results of

global challenges when SSD is not shared need not be reported since the home system is

the one performing the authentication.

SSDShared

No

AuthResult

Yes

no report

SuccessFail

AFREPORT

Global challenge

Authentication is

performed by thehome system so noreporting is needed

Figure 5-17: Authentication reporting for unique challenges

1

1

2

3

4

5

6

7

8

9

10

11

2


35/81

6. Unique Challenges

Unlike global challenges that require all

mobile stations to provide authentication

parameters before accessing the system,

a unique challenge is directed at a

specific mobile station. Unique

challenges may be used instead of or in

addition to global challenges and may be

initiated by either visited or home

systems, regardless of whether SSD is

shared. Figure 6-18: Unique challenge to MS

Roaming mobile stations being uniquely challenged in a visited system will receive a unique

challenge message as shown above. This message may be received over paging, access,

or dedicated traffic channels.

6.1 Authentication signature (AUTHU)

As with the global challenge, the basis for authentication is the ability for both the MS and

the authentication controller (i.e. visited VLR or home AC) to generate authentication

signatures that may be compared. In the case of a unique challenge, the authentication

signature is referred to as the AuthenticationResponseUniqueChallenge (AUTHU) and is

calculated using the CAVE algorithm with inputs illustrated below. Note that the inputs used

in generating AUTHU for unique challenges differ from the inputs used in generating AUTHRfor global challenges.

Figure 6-19: Generation of AUTHU for unique challenge

VisitedSystem

authentication challengeRANDU

Random Challenge (32-bit)24-bit RANDU received in uniquechallenge message + 8-bit IMSI_S2

ESN (32-bit)ESN provisioned in MS

Authentication Data(24-bit)IMSI_S1 (i.e. last 6 digits of MIN)

Secret Data (64-bit)SSD_A part of SSD generated usingCAVE and provisioned A-key

CAVEalgorithm

AUTHU (18-bit)Authentication

Signature

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

2


36/81

Upon receiving a unique challenge, the MS generates and includes an AUTHU value in a

unique challenge response message. The visited system compares the AUTHU value

received from the MS with the AUTHU value either generated by the visited VLR or received

from the home AC to determine whether the MS is authentic. Unlike the global challenge,

comparison of AUTHU values is always performed by the visited system, even when thechallenge is initiated and AUTHU value generated by the home system.

6.2 Unique challenge initiated by roamers home system

A roamers home system may initiate a unique challenge at any time and regardless of

whether SSD has been shared with the visited VLR. In fact, even if SSD has been shared

and the visited network has successfully performed global and unique challenges on the

roamer, the home system may still initiate a unique challenge at its discretion.

If the unique challenge is initiated by the home system, the AUTHU will be generated by the

home AC and provided to the visited system in an Authentication Directive (AUTHDIR)

message as shown below. This AUTHDIR will also include the

RandomVariableUniqueChallenge (RANDU) that was used to generate the AUTHU.

Figure 6-20: Unique challenge initiated by roamers home system

Because the visited system performs the comparison of AUTHU values generated by the MS

and home system, results of the unique challenge must be reported to the home system

regardless of whether the challenge succeeds or fails.

VisitedSystem

HomeHLR/AC


AUTHDIRRANDU, AUTHU

ASREPORTunique challenge report

authdir

auth challenge responseAUTHU

asreport

SSDSSD

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

2


37/81

6.3 Unique challenge initiated locally by visited system

If SSD is shared with the visited VLR, the visited system is able to initiate a unique challenge

and generate an AUTHU locally to compare to the one received from the MS. The call flow

for a visited system initiated unique challenge is illustrated below.

Figure 6-21: Unique challenge initiated by visited system

Note that when initiated by the visited system, results of a unique challenge only need to be

reported to the home system if the challenge fails; otherwise, the home system is not

involved in the authentication attempt.

6.4 Reporting results to roamers home system

When a roamers home system initiates a unique challenge, the visited system will send an

AuthenticationStatusReport Invoke (ASREPORT) message upon completing the challenge

attempt to inform the home system whether the authentication was successful. However,

when unique challenges are initiated locally by the visited system, the home system only

needs to be informed of failed authentication attempts as illustrated below.

VisitedSystem

HomeHLR/AC


AFREPORTunique challenge report

auth challenge responseAUTHU

asreport

Failure reportis

Fraud WG CDG138 CDMA Authentication

Documents