鉴权过程

鉴权是一种移动台与基站之间的信息交换过程，证实移动台的识别。

Ø

鉴权采用的是“公钥－密钥机制”。
移动台与基站各有一个密钥（SSD ：共用加密数据），移动台的密钥保存在半永久存储器中，基站的密钥保存在HLR/AC 中。密钥只有移动台和HLR/AC 知道，是不可以在空中传递的，是严格对外保密的。
公钥是由移动台或者基站产生的一个随机数，可以在两者之间传递，是非保密的。移动台和对应基站的公钥是一样的。

Ø

移动台和基站分别利用各自的公钥和密钥通过“鉴权特征程序”产生各自的“鉴权码”，然后比较两者的鉴权码，如果鉴权码相同，表明鉴权通过；否则鉴权不通过。

Ø1、基站发送SSD更新消息，其中RANDSSD字段包含与HLR/AC计算出的SSD同样的值。
Ø2、双方设置SSD生成程序的输入参数，并运行SSD生成程序。
Ø3、移动台选择32比特的随机数，RANDBS，并通过基站查询指令消息发往基站。
Ø4、双方设置并运行鉴权特征程序。AUTHBS为18比特的输出结果，基站通过基站查询证实指令把此值发往移动台。
[size=89%]若移动台收到基站查询证实指令前没有收到SSD更新消息，则以SSD更新拒绝指令消息响应
Ø5、移动台进行比较：
[size=89%]成功，更新SSD_A，SSD_B，向基站发送SSD更新证实指令消息

[size=89%]失败，向基站发送SSD更新拒绝指令消息

Ø6、基站收到SSD更新证实指令后，基站将SSD_A，SSD_B设置为从HLR/AC中收到的

在接入状态过程中由基站发起请求鉴权：

Authentication Challenge Message：signal is CAI_PC_AUTH_MSG

然后在mccsa_process_layer3里进行处理根据基站提过的randu计算auth，之后将计算得到的结果发送到bs，如果计算失败发CAI_NO_AUTH
Ø通常由基站发起鉴权要求，并产生一个随机数RAND作为公钥发给移动台。
Ø移动台利用这个公钥和自己存储的密钥，通过“鉴权特征程序”计算出鉴权码AUTHU，然后发给基站。
Ø基站将收到的AUTHU与自己计算出的AUTHU比较，如果相同，鉴权通过，否则鉴权失败。
Ø如果鉴权失败，首先怀疑是否公钥RAND传递时出错，基站会重新生成一个公钥RAND发给移动台，要求其再进行一次鉴权操作。
Ø如果鉴权还是失败，怀疑可能是移动台和基站各自存储的密钥SSD不一致，基站会产生一个随机数RANDSSD发给移动台，由移动台和基站用特定程序在本地各自生成一个新的密钥SSD。并改由移动台（而不是基站）产生公钥RAND发给基站。然后各自计算AUTHU，再由基站把它的AUTHU发给移动台，在移动台处进行AUTHU的比较，如果还是不相同，鉴权便彻底失败，基站会拒绝为移动台提供服务。如果相同，鉴权成功，同时更新移动台和基站的密钥SSD。

in system acess substate:

1、mccsa_proc_msg :acess rxtx msg

2、when accept a CAI_PC_AUTH_MSG begin auth signature

3、skip to mccsa_process_layer3

4、case CAI_PC_AUTH_MSG:

mccsa_send_order_response_msg

5、case CAI_AC_AUTH_RESP_MSG

mcc_auth_cmd( auth_cmd_ptr )to calculate the auth

mccsa_send_access_cmd :send auth to bs(need ack)

如果基站匹配auth失败，会开始send ssd update

1、case CAI_PC_SSD_UP_MSG:

EVDO鉴权

EVDO have two steps of authentication,  first one is for AN authentication and second step is for SN authentication. Mostly AN and SN authentication will use CHAP instead of PAP for AUTH.

The authentication protocol is negotiated during LCP configuration procedure.

AN authentication：

AN authentication is also called A12 authentication. It is a procedure that EVDO Access Network (AN) uses to authenticate Access Terminal (AT). In most of the EVDO network deployments Worldwide, AN typically use Challenge Handshake Authentication Protocol (CHAP) to authenticate the AT.

 

Detail: 

Who triggers AN authentication?
AN authentication is always initiated by AN. AT typically operates in the passive mode, in other words, AT will not initiate this procedure but will respond back when challanged by AN.

 

When does AN authentication happen?
It mainly depends upon Infra-vendor's AN design. But from AT perspective, it can happen any time and thus, AT needs to be prepared to deal with it.

 

What is call flow for AN authentication?
To start AN authentication, AN sends out LCP Configuration Request to AT on AN stream. During LCP configuration phase, CHAP authentication option is negotiated. After LCP negotiation is completed successfully, Network sends CHAP Challenge, which starts authentication phase. Network responds CHAP Success orCHAP Failure based on CHAP Response composed by AT. AN authentication is completed at this point.

开机接入流和接入鉴权流程：

a. 建立空口会话，其中包括  UATI 分配 、会话配置协商和 DH密钥交换等过程。 
b. AT向AN发送开启请求消息，请求开启 AN流；AN返回开启响应消息，开启 AN流。  
c. AN与 AT 之间进行 PPP 和 LCP协商，主要协商 PPP 数据分组的大小和鉴权协议类型
d. AN发起接入鉴权，向 AT 发送 CHAP 查询消息，其中包含鉴权随机数。 
e. AT收到该消息后， 根据鉴权随机数， 使用MD5算法计算鉴权结果， 并向AN发送CHAP响应消息，该消息中包含 NAI、CHAP Password 和 CHAP-Challenge 等接入鉴权参数。 
f. AN收到AT上报的CHAP 响应消息后，向 AN-AAA 发送A12接入请求消息，其中包
含 NAI、CHAP Password、CHAP-Challenge 和 AN-IP等鉴权参数。 
g. AN-AAA 根据 A12 接入请求消息中的鉴权参数，使用 MD5 算法计算鉴权结果，并与
AT 上报的鉴权结果进行比较。若两者一致，则 AN-AAA 向 AN 发送 A12 接入允许消息，允许AT接入到1x EV-DO网络，该消息中还包含MNID（或 IMSI） ，用于建立和标识R-P连接；