通信網(wǎng)banner.jpg)
隨著眾多業(yè)務(wù)的開(kāi)展，運(yùn)營(yíng)商和用戶(hù)都需要可靠的認(rèn)證機(jī)制來(lái)保證合法的業(yè)務(wù)使用以及正確的計(jì)費(fèi)。尤其是在3G業(yè)務(wù)中，很多應(yīng)用都需要在用戶(hù)端（例如UE）和應(yīng)用服務(wù)器之間進(jìn)行雙向認(rèn)證，比如客戶(hù)端和presence服務(wù)器間的通信，客戶(hù)端申請(qǐng)數(shù)字證書(shū)時(shí)與PKI入口的通信等等。而眾多業(yè)務(wù)如果各自使用自己獨(dú)立的認(rèn)證，就會(huì)造成屢次更換設(shè)備。而且由于許多應(yīng)用都需要同級(jí)別的認(rèn)證機(jī)制，因此有必要定義一種通用認(rèn)證架構(gòu)（GAA）。
GAA[1]就是旨在提供一種通用的鑒權(quán)機(jī)制，既可以用于現(xiàn)有的服務(wù)，也可以用于將來(lái)的新業(yè)務(wù)，從而避免為每一種新服務(wù)都提供獨(dú)有的鑒權(quán)機(jī)制。不同應(yīng)用的一個(gè)通用機(jī)制避免了各種機(jī)制之間的差異性，從而能以一種一致的方式解決安全認(rèn)證的問(wèn)題。
2、GAA介紹
在系統(tǒng)中通常有兩種認(rèn)證機(jī)制。一種基于通信實(shí)體間的共享秘密，另一種基于公鑰的證書(shū)。如圖1所示。
1）基于實(shí)現(xiàn)共享秘密機(jī)制
基于通信實(shí)體間事先共享秘密機(jī)制的有若干個(gè)認(rèn)證協(xié)議，常有的包括HTTP Digest和IKE協(xié)議。這類(lèi)認(rèn)證機(jī)制的主要問(wèn)題在于如何在該事先共享秘密上達(dá)成一致。GAA中的GBA部分將描述如何在移動(dòng)的上下文環(huán)境中使用基于認(rèn)證和密鑰協(xié)商（AKA）的機(jī)制，從而為通信實(shí)體提供事先共享秘密。
2）基于公鑰證書(shū)的認(rèn)證
除了使用共享秘密認(rèn)證外，另外一種方法基于非對(duì)稱(chēng)密碼方法進(jìn)行認(rèn)證。該認(rèn)證方法假設(shè)需要認(rèn)證的實(shí)體（通信單方或者雙方）擁有一個(gè)密鑰對(duì)（公有和私有）以及相應(yīng)的數(shù)字證書(shū)。后者驗(yàn)證該密鑰對(duì)并綁定到其合法擁有者。眾所周知的基于密鑰對(duì)（公有和私有）的協(xié)議包括PGP協(xié)議、TLS上的HTTP（后者常用其協(xié)議名稱(chēng)HTTPS稱(chēng)呼）。
這類(lèi)認(rèn)證方法的主要缺點(diǎn)在于需要PKI，非對(duì)稱(chēng)的密鑰操作與對(duì)稱(chēng)的密鑰操作相比，經(jīng)常需要更多的計(jì)算量。GAA中的“用戶(hù)證書(shū)支持”（SSC）部分描述了一個(gè)移動(dòng)運(yùn)營(yíng)商如何能夠給其用戶(hù)頒發(fā)數(shù)字證書(shū)（因而提供基本PKI）。
3、GAA的組成
如圖1所示，GBA（通用Bootstrapping架構(gòu)）[2]和證書(shū)（Certificates）[3]是GAA的主要構(gòu)成單元。
1）GBA（Gneric Bootstrapping Architecture）
GBA有兩種，2G的GBA和3G的GBA，這里主要描述了3G的GBA。GBA旨在描述如何在移動(dòng)的上下文環(huán)境中，使用基于3GPP AKA[5]的機(jī)制為客戶(hù)端（UE）和應(yīng)用服務(wù)器提供事先共享秘密。隨后，該共享秘密能用于認(rèn)證客戶(hù)和應(yīng)用程序服務(wù)器之間的通信。
AKA是移動(dòng)網(wǎng)絡(luò)所用的一個(gè)非常普遍的認(rèn)證機(jī)制。GBA重用AKA機(jī)制來(lái)逐步實(shí)現(xiàn)（bootstrap）應(yīng)用的安全。如下圖所示，GBA引入了一個(gè)新的網(wǎng)元BSF，其通過(guò)與HSS之間的接口獲得用戶(hù)安全信息和認(rèn)證信息。UE和BSF之間運(yùn)行AKA認(rèn)證機(jī)制，并根據(jù)運(yùn)行結(jié)果（即加密性密鑰CK和完整性密鑰IK），在BSF和UE之間產(chǎn)生一個(gè)會(huì)話(huà)密鑰。一個(gè)應(yīng)用服務(wù)器（NAF）能從BSF獲得該會(huì)話(huà)密鑰和簽約用戶(hù)檔案（Profile）。通過(guò)這種方式，NAF和UE就能擁有一個(gè)共享密鑰，該共享密鑰能為隨后的應(yīng)用提供安全保護(hù)，特別是在應(yīng)用會(huì)話(huà)開(kāi)始時(shí)認(rèn)證UE和NAF。而且UE和BSF之間的通信、NAF和BSF之間的通信、BSF和HSS之間的通信獨(dú)立于具體應(yīng)用，所以是通用的。
2）證書(shū)（Certificates）
如果一個(gè)客戶(hù)想利用非對(duì)稱(chēng)加密技術(shù)，他需要一個(gè)由認(rèn)證中心（CA）[8]生成的數(shù)字證書(shū)。該數(shù)字證書(shū)是將一個(gè)公開(kāi)密鑰和其合法擁有者的身份信息綁定在一起，并用來(lái)證明該公開(kāi)密鑰的合法性。如果一個(gè)移動(dòng)用戶(hù)想擁有和使用密鑰對(duì)（公、私密鑰對(duì)），該密鑰對(duì)和證書(shū)應(yīng)被預(yù)載，或該移動(dòng)用戶(hù)必須有方法生成或獲取一個(gè)密鑰對(duì)并自動(dòng)獲得其相應(yīng)的數(shù)字證書(shū)。
為自動(dòng)獲得一個(gè)數(shù)字證書(shū)，UE必須向歸屬運(yùn)營(yíng)商的公鑰基礎(chǔ)結(jié)構(gòu)入口（PKI Portal）發(fā)送發(fā)送證書(shū)請(qǐng)求，該P(yáng)KI Portal必須認(rèn)證該證書(shū)請(qǐng)求。事實(shí)上，證書(shū)注冊(cè)過(guò)程，即發(fā)放一個(gè)證書(shū)給用戶(hù)和在UE和PKI Portal之間的相應(yīng)通信會(huì)話(huà)，就是一個(gè)移動(dòng)應(yīng)用實(shí)例，UE和PKI Portal之間需要進(jìn)行認(rèn)證（后者相當(dāng)于一個(gè)應(yīng)用服務(wù)器）。此處的認(rèn)證基于PKI Portal和UE之間的預(yù)共享加密，如果該共享秘密沒(méi)有提前預(yù)置，則GBA能用來(lái)獲得這樣一個(gè)共享秘密。
一旦移動(dòng)用戶(hù)擁有一個(gè)（公、私）密鑰對(duì)和一數(shù)字證書(shū)，他就能用該證書(shū)和相應(yīng)的密鑰對(duì)來(lái)處理數(shù)字簽名（如移動(dòng)電子商務(wù)應(yīng)用）和HTTPS等應(yīng)用。
4、GBA過(guò)程
4.1 網(wǎng)絡(luò)元素與參考點(diǎn)的功能和要求
1）Bootstrapping服務(wù)功能（BSF）
Bootstrapping服務(wù)功能（BSF）處于用戶(hù)的歸屬網(wǎng)絡(luò)中。通過(guò)Zh接口，BSF可以從HSS獲得GBA的用戶(hù)安全設(shè)置（GUSS）；通過(guò)Ub接口，和UE利用AKA協(xié)議進(jìn)行相互認(rèn)證，并且建立會(huì)話(huà)密鑰，這個(gè)密鑰將應(yīng)用在UE和NAF之間；通過(guò)Zn/Zn接口，BSF可以將該密鑰和用戶(hù)安全設(shè)置傳遞給NAF。
2）NAF
Bootstrapping結(jié)束以后，UE和NAF可以通過(guò)參考點(diǎn)Ua運(yùn)行一些應(yīng)用相關(guān)協(xié)議，在這些協(xié)議里面，消息的認(rèn)證都是基于在UE和BSF相互認(rèn)證過(guò)程中所產(chǎn)生的會(huì)話(huà)密鑰。
在Bootstrapping前，UE和NAF之間以前沒(méi)有安全關(guān)聯(lián)。為了通過(guò)參考點(diǎn)Zn從BSF獲取UE和BSF達(dá)成的共享密鑰，NAF應(yīng)該能夠定位并且能夠與用戶(hù)歸屬網(wǎng)絡(luò)的BSF進(jìn)行安全的通信。并且，NAF能夠根據(jù)本地策略設(shè)置共享密鑰的本地有效情況、檢測(cè)共享密鑰的生存期、以及與UE采取措施來(lái)保證GBA中密鑰的刷新。
3）D-Proxy
當(dāng)UE被連接到一個(gè)外地網(wǎng)絡(luò)的NAF時(shí)，這個(gè)拜訪(fǎng)的NAF需要利用NAF網(wǎng)絡(luò)的D-Proxy與用戶(hù)的BSF（歸屬網(wǎng)絡(luò)的BSF）進(jìn)行通信。此時(shí)，D-Proxy在拜訪(fǎng)NAF和用戶(hù)的歸屬BSF之間起到代理的作用，必須能夠找到用戶(hù)的歸屬BSF并且可以通過(guò)安全信道與之通信。
4）HSS
所有的用戶(hù)安全設(shè)置，也就是GUSS，都存儲(chǔ)在HSS中。一個(gè)用戶(hù)具有多個(gè)訂閱業(yè)務(wù)情況下，HSS就會(huì)包含一個(gè)或者多個(gè)GUSS，這些GUSS可以映射到一個(gè)或者多個(gè)私有身份（比如說(shuō)IMPI、IMSI）。
而GUSS應(yīng)該包含應(yīng)用相關(guān)用戶(hù)安全設(shè)置（USS），這些用戶(hù)安全設(shè)置包含著與UICC增強(qiáng)型GBA情況下密鑰選擇（Ks_ext_NAF還是Ks_int_NAF）、與一個(gè)或者多個(gè)應(yīng)用的認(rèn)證和鑒權(quán)信息相關(guān)的參數(shù)。
5）UE
為了和BSF達(dá)成共享密鑰，UE必須支持HTTP DIGEST AKA[7]協(xié)議，并且能夠利用CK和IK，產(chǎn)生在Ua接口上與應(yīng)用一起使用的密鑰資料，以及支持與NAF應(yīng)用相關(guān)的協(xié)議，如HTTPS等。
根據(jù)終端UICC能力的不同，GBA可以分為GBA_ME和GBA_U。前者密鑰的協(xié)商和生成都在ME中完成，而后者密鑰的協(xié)商和生成都在UICC中完成，因此安全性更高。一個(gè)支持GBA的ME應(yīng)該支持GBA_U和GBA_ME兩種方式。當(dāng)采用GBA_U方式時(shí)，BSF和UE之間達(dá)成的共享密鑰有Ks_int_NAF和Ks_ext_NAF兩種，并且Ks_int_NAF保存在UICC中，不能泄漏給ME，而Ks_ext_NAF會(huì)由UICC發(fā)送給ME；當(dāng)采用GBA_ME方式時(shí)，達(dá)成的共享密鑰為Ks_NAF。
當(dāng)應(yīng)用層的客戶(hù)端在ME中時(shí)，Ks_ext_NAF應(yīng)該被用作共享密鑰；當(dāng)應(yīng)用層的客戶(hù)端在UICC中時(shí)，Ks_int_NAF應(yīng)該被用作共享密鑰。
4.2 過(guò)程
1）初始化
在開(kāi)始GBA過(guò)程之前，UE和NAF必須協(xié)商好是否采用GBA。一般是由UE首先向NAF發(fā)送請(qǐng)求（不包括任何GBA相關(guān)信息）；如果NAF需要使用GBA達(dá)成共享密鑰，則由NAF返回Bootstrapping初始化信息。
2）Bootstrapping過(guò)程
在完成上面初始化步驟后或者UE內(nèi)的密鑰已經(jīng)過(guò)期時(shí)，UE開(kāi)始啟動(dòng)如圖4所示的Bootstrapping過(guò)程。
�、賃E向BSF發(fā)送HTTP請(qǐng)求。
�、谕ㄟ^(guò)參考點(diǎn)Zh，BSF從HSS中獲得GBA用戶(hù)的全部安全參數(shù)設(shè)置和一個(gè)認(rèn)證向量（AV，AV=RAND||AUTN||XRES||CK||IK）。
③BSF通過(guò)401消息把隨機(jī)數(shù)RAND和AUTN（不發(fā)送CK，IK和XRES）發(fā)送給UE。
�、躑E利用RAND值，計(jì)算AUTN值，并與BSF發(fā)送過(guò)來(lái)的AUTN進(jìn)行比對(duì)，如果一致，則成功認(rèn)證網(wǎng)絡(luò)；UE還計(jì)算出CK、IK和RES。這樣，BSF和UE都擁有了密鑰IK和CK。
�、軺E發(fā)送另一個(gè)HTTP請(qǐng)求到BSF，其中包含著摘要AKA響應(yīng)（使用RES計(jì)算出來(lái)的）。
�、轇SF將摘要AKA響應(yīng)，與使用XRES計(jì)算出來(lái)的進(jìn)行比對(duì)，從而對(duì)UE進(jìn)行鑒權(quán)。
�、呷绻b權(quán)成功，BSF通過(guò)CK和IK來(lái)產(chǎn)生密鑰資料Ks。并且根據(jù)第三步中的RAND和BSF服務(wù)器名進(jìn)行編碼，以NAI的格式來(lái)產(chǎn)生B-TID值。（B-TID，能夠唯一標(biāo)識(shí)該次Bootstrapping事件，以后NAF可以根據(jù)這個(gè)值向BSF索取達(dá)成的相關(guān)密鑰Ks_NAF）。
�、郆SF發(fā)送200 OK消息到UE通知認(rèn)證成功，該消息中包含B-TID，以及密鑰Ks的生存期。在UE中也根據(jù)CK和IK產(chǎn)生密鑰資料Ks。
�、嵩谑褂胋ootstrapped安全關(guān)聯(lián)的過(guò)程中，根據(jù)該Ks，UE和BSF利用Ks產(chǎn)生密鑰資料Ks_NAF，來(lái)保證參考點(diǎn)Ua的安全。Ks_NAF根據(jù)公式KDF（Ks，“gba-me”，RAND，IMPI，NAF_Id）來(lái)計(jì)算，在GBA_ME模式中，該計(jì)算應(yīng)該在BSF和UE內(nèi)的ME執(zhí)行。
注：BSF應(yīng)該通過(guò)Zh接口從HSS中的用戶(hù)安全信息中獲得IMPI。另外，UE和BSF需要保持NAF名（即NAF_Id）的一致性，保存密鑰Ks和相關(guān)的B-TID，直到Ks的生存期滿(mǎn)或者密鑰Ks被更新了。
4.3 安全關(guān)聯(lián)的過(guò)程
在GBA完成以后，UE和BSF之間達(dá)成了共享密鑰Ks。UE也用上一節(jié)中的步驟中產(chǎn)生Ks_NAF，然而NAF還并沒(méi)有獲得該密鑰的有關(guān)信息。為了在UE和NAF之間達(dá)成共享密鑰以進(jìn)行通信，還需要如圖5所示的步驟：
①UE向NAF發(fā)起請(qǐng)求
其中，UE和NAF必須進(jìn)行協(xié)商，是否已經(jīng)建立起共享密鑰（Ks_NAF），如果是，則立刻可以開(kāi)始安全通信；否則，如果還沒(méi)有建立共享密鑰或者密鑰已經(jīng)過(guò)期需要更新，UE需要和BSF發(fā)起GBA過(guò)程去獲得Ks和Ks_NAF。
�、贜AF通過(guò)參考點(diǎn)Zn與BSF開(kāi)始通信
�、跙SF收到來(lái)自NAF的請(qǐng)求以后，BSF首先驗(yàn)證NAF主機(jī)名的有效性。然后根據(jù)該已經(jīng)達(dá)成的Ks，和收到的NAF_Id以及其他密鑰衍生參數(shù)根據(jù)上節(jié)步驟9計(jì)算出Ks_NAF，并和用戶(hù)安全設(shè)置一起發(fā)給NAF。
④NAF收到Ks_NAF和可能的用戶(hù)安全設(shè)置后，可以進(jìn)行本地策略設(shè)置。然后，NAF把Ks_NAF應(yīng)用在參考點(diǎn)Ua上的協(xié)議中，繼續(xù)與UE進(jìn)行交互。
至此，完成了Bootstrapping的過(guò)程。
5、基于UICC的增強(qiáng)型GBA（GBA_U）
如前所述，當(dāng)采用GBA_U時(shí)，密鑰的協(xié)商和生成都由UICC完成。這種增強(qiáng)型的GBA對(duì)UE和BSF都提出了新的要求。
5.1 UE的要求
在參考點(diǎn)Ub上的協(xié)議所產(chǎn)生的CK、IK及Ks不能離開(kāi)UICC。收到ME的請(qǐng)求后，UICC必須通過(guò)GBA衍生出bootstrapping密鑰Ks，還必須能利用存儲(chǔ)在UICC上的Ks衍生出NAF相關(guān)密鑰Ks_int_NAF以及Ks_ext_NAF。
5.2 BSF的要求
BSF應(yīng)能支持GBA_U和GBA_ME兩種Bootstrapping方式，使用哪一種方式取決于簽約信息（即UICC能力）。而B(niǎo)SF應(yīng)可以從HSS中獲得的GBA用戶(hù)安全設(shè)置中獲知與GBA相關(guān)的UICC能力。
5.3 GBA_U的過(guò)程
Bootstrapping的初始化與GBA_ME相同。下面詳細(xì)的過(guò)程只是多加了一個(gè)UICC到ME之間的內(nèi)部接口信息的傳遞過(guò)程，計(jì)算MAC的方式略微有所不同，具體請(qǐng)參考[2]。
5.4 使用Bootstrapped安全關(guān)聯(lián)的過(guò)程
其過(guò)程與GBA_ME相似，差別在于：
�、賃E和NAF在協(xié)商密鑰的時(shí)候，需要約定好采用Ks_int_NAF還是Ks_ext_NAF。
②如果共享密鑰為Ks_ext_NAF，則在UICC完成步驟GBA_U過(guò)程中步驟9中的密鑰產(chǎn)生后，需要實(shí)現(xiàn)與ME之間密鑰Ks_ext_NAF的傳遞。
6、支持用戶(hù)證書(shū)（SSC）
圖6展示了用戶(hù)證書(shū)支持的網(wǎng)絡(luò)模型參考圖，其中包括證書(shū)發(fā)放相關(guān)的網(wǎng)絡(luò)實(shí)體及連接它們之間的參考點(diǎn)。PKI Portal的作用相當(dāng)于前面講到的NAF。在PKI[9]向UE通過(guò)參考點(diǎn)Ua頒發(fā)用戶(hù)證書(shū)和運(yùn)營(yíng)商CA證書(shū)時(shí)，應(yīng)當(dāng)使用基于Ub接口上的GBA過(guò)程得到的共享密鑰進(jìn)行認(rèn)證。通過(guò)Zn接口，PKI可以從BSF處得到該密鑰。
在用戶(hù)證書(shū)的發(fā)放過(guò)程中，UE可能會(huì)向PKI Portal請(qǐng)求一個(gè)公鑰的證書(shū)，請(qǐng)求格式是PKCS#10[8]，用來(lái)封裝公鑰和其他屬性（即用戶(hù)名、密鑰用途等等）。接收到證書(shū)請(qǐng)求之后，根據(jù)BSF從HSS得到的特定用戶(hù)安全設(shè)置，以及自己的證書(shū)操作策略，PKI Portal對(duì)公鑰進(jìn)行驗(yàn)證。如果PKI Portal通過(guò)該公鑰的認(rèn)證，它將生成相應(yīng)的證書(shū)，并通過(guò)參考點(diǎn)Ua傳回UE。
在運(yùn)營(yíng)商CA證書(shū)的發(fā)送過(guò)程中，UE可能會(huì)請(qǐng)求PKI Portal發(fā)送運(yùn)營(yíng)商CA的證書(shū)。在相應(yīng)的響應(yīng)中，PKI Portal將把CA的證書(shū)發(fā)送給UE。
在發(fā)放以上兩種證書(shū)的過(guò)程中，認(rèn)證、完整性保護(hù)以及對(duì)通過(guò)參考點(diǎn)Ua傳送的信息可能進(jìn)行的加密都是基于UE-BSF之間生成的共享秘鑰，即Ks_（ext/int）_NAF。為了敘述方便，在下面的過(guò)程中提到Ks_NAF的地方，實(shí)際上意味著Ks_（ext/int）_NAF。
7、結(jié)束語(yǔ)
本文詳細(xì)介紹了3GPP推出的通用認(rèn)證框架GAA的作用、結(jié)構(gòu)和使用的過(guò)程。隨著日益增多的業(yè)務(wù)應(yīng)用，GAA勢(shì)必能夠幫助解決屢次需要更新用戶(hù)卡來(lái)支持新的認(rèn)證方式的問(wèn)題。這樣，尤其對(duì)于中國(guó)機(jī)卡分離的運(yùn)營(yíng)模式下的用戶(hù)可以配置更為先進(jìn)的認(rèn)證方式，而不用經(jīng)常替換SIM卡，從而節(jié)約了很大的成本，并且使得運(yùn)營(yíng)更為靈活。所以從這個(gè)意義上來(lái)說(shuō)，確實(shí)不失為一種值得考慮的通用機(jī)制。
8、縮略語(yǔ)
9、參考文獻(xiàn)
[1] 3GPP TR 33.919:“3rd Generation Partnership Project； Technical Specification Group Services and System Aspects； Generic Authentication Architecture (GAA)；System description”.
[2] 3GPP TS 33.220:“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects； 3G Security；Generic Authentication Architecture(GAA)；Generic bootstrapping architecture”.
[3] 3GPP TS 33.221:“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects； 3G Security；Generic Authentication Architecture(GAA)；Support for subscriber certificates”.
[4] 3GPP TS 33.222:“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects； 3G Security；Generic Authentication Architecture(GAA)；Access to network application functions using secure hypertext transfer protocol (HTTPS)”
[5] 3GPP TS 33.102:“3rd Generation Partnership Project；Technical Specification Group Services and System Aspects； 3G Security；Security architecture”.
[6] IETF RFC 3310 (2002):“Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)”
[7] IETF RFC 2617 (1999):“Franks J,et al”,“ HTTP Authentication: Basic and Digest Access Authentication”,RFC? 2617, June 1999.
[8] PKCS#10:“Certification Request Syntax Standard”.
[9] OMA:“Wireless Identity Module；Part: Security”.
