專利名稱：一種業(yè)務(wù)實(shí)體認(rèn)證方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信領(lǐng)域，特別涉及一種端到端認(rèn)證框架中實(shí)現(xiàn)業(yè)務(wù)實(shí)體的認(rèn)證方法及裝置。
背景技術(shù)：
大多數(shù)應(yīng)用服務(wù)器在向移動(dòng)用戶提供某一業(yè)務(wù)時(shí)，都應(yīng)該首先與用戶建立相互信任的關(guān)系(例如移動(dòng)用戶與認(rèn)證代理之間，移動(dòng)用戶與公鑰基礎(chǔ)設(shè)施(PKI-Public Key-Infrastructure)證書機(jī)構(gòu)之間，移動(dòng)用戶與內(nèi)容提供服務(wù)器之間等)。一般來說，這種信任關(guān)系是在移動(dòng)用戶與應(yīng)用服務(wù)器之間的雙向認(rèn)證過程中確立的。
在3GPP(3rd Generation Project Partnership-第三代合作伙伴計(jì)劃)中，提出了3GPP中的通用鑒權(quán)框架。參見圖1，為該框架的結(jié)構(gòu)示意圖。通用鑒權(quán)框架通常由用戶201、執(zhí)行用戶身份初始檢查驗(yàn)證的實(shí)體(BSF-BootstrappingServer Function)202、用戶歸屬網(wǎng)絡(luò)服務(wù)器(HSS-Home Subscriber System)203，和網(wǎng)絡(luò)業(yè)務(wù)應(yīng)用實(shí)體(NAF-Network Application Function)204組成。BSF 202用于與用戶201進(jìn)行互驗(yàn)證身份，同時(shí)生成BSF 202與用戶201的共享密鑰；HSS 203中存儲用于描述用戶信息的描述(Profile)文件，同時(shí)HSS 203還兼有產(chǎn)生鑒權(quán)信息的功能。
用戶在使用NAF所提供的業(yè)務(wù)前首先要通過BSF的認(rèn)證。用戶與BSF之間的互認(rèn)證過程是用戶向BSF發(fā)出鑒權(quán)請求，鑒權(quán)請求消息中包括用戶的永久身份標(biāo)識IMPI或由IMSI轉(zhuǎn)換得到的永久身份標(biāo)識IMPI，BSF接到來自用戶的鑒權(quán)請求后，首先到HSS獲取該用戶的鑒權(quán)信息，BSF向HSS請求鑒權(quán)的消息中也包含了用戶的永久身份標(biāo)識，HSS根據(jù)用戶的永久身份標(biāo)識查找到該用戶的屬性信息并且生成鑒權(quán)矢量返回給BSF，BSF根據(jù)所獲取的鑒權(quán)信息與用戶之間執(zhí)行AKA(鑒權(quán)和密鑰協(xié)商協(xié)議)進(jìn)行互鑒權(quán)。鑒權(quán)成功后，用戶和BSF之間互相認(rèn)證了身份并且同時(shí)生成了共享密鑰Ks，BSF為這個(gè)密鑰Ks定義了一個(gè)有效期限，以便Ks進(jìn)行更新。之后，BSF分配一個(gè)會話事務(wù)標(biāo)識(B-TID)給用戶，在將B-TID發(fā)送給用戶的同時(shí)包含了Ks的有效期限，該B-TID是與Ks相關(guān)聯(lián)的。共享密鑰Ks是作為根密鑰來使用的，不會離開用戶和BSF，當(dāng)用戶和NAF通信時(shí)，將使用由Ks衍生出的密鑰。
該通用鑒權(quán)框架的缺點(diǎn)是用戶與BSF認(rèn)證只支持一種認(rèn)證方式(即AKA的認(rèn)證方式)，對于不支持AKA認(rèn)證的用戶，無法完成認(rèn)證，從而使得該框架只適用于3GPP無線網(wǎng)絡(luò)的移動(dòng)用戶使用應(yīng)用業(yè)務(wù)的情況，有很大的局限性。
另外該認(rèn)證機(jī)制沒有提供BSF與NAF的認(rèn)證，容易使攻擊者假冒NAF竊取用戶的一些機(jī)密信息。
在3GPP2中，也存在一種通用的鑒權(quán)框架，參見圖2，為該框架示意圖。3GPP2中的通用鑒權(quán)框架由移動(dòng)節(jié)點(diǎn)(MN-Mobile Node)301，網(wǎng)絡(luò)業(yè)務(wù)應(yīng)用實(shí)體(NAF-Network Application Function)302，執(zhí)行用戶身份初始檢查驗(yàn)證的實(shí)體(BSF)303，用戶歸屬網(wǎng)絡(luò)服務(wù)器(HSS)304，用戶歸屬位置寄存器以及鑒權(quán)中心(HLR/AC)，和認(rèn)證授權(quán)計(jì)費(fèi)服務(wù)器(AAA)組成。
MN要使用NAF提供的業(yè)務(wù)首先需要與BSF進(jìn)行互認(rèn)證，互認(rèn)證方式有3種(包括AKA、基于CAVE的認(rèn)證方式、基于AAA的認(rèn)證方式)可以根據(jù)MN以及網(wǎng)絡(luò)支持情況，以及運(yùn)營商本地策略靈活選擇。
該通用鑒權(quán)框架有以下缺點(diǎn)雖然3GPP2中的MN與BSF間的認(rèn)證方式可以協(xié)商，但它只支持三種認(rèn)證方式，當(dāng)用戶或網(wǎng)絡(luò)不支持這三種中的任何一種時(shí)(例如Kerberos認(rèn)證機(jī)制)，則不能使用該鑒權(quán)框架，使得鑒權(quán)框架仍然不能適用于在多種網(wǎng)絡(luò)中業(yè)務(wù)實(shí)體在進(jìn)行業(yè)務(wù)通信前與網(wǎng)絡(luò)的互認(rèn)證，故仍然存在一定的局限性。
另外該認(rèn)證機(jī)制仍然沒有提供BSF與NAF的認(rèn)證，容易使攻擊者假冒NAF竊取用戶的一些機(jī)密信息。
發(fā)明內(nèi)容
為了克服現(xiàn)有技術(shù)中存在鑒權(quán)框架不能適用于多種網(wǎng)絡(luò)，并且業(yè)務(wù)提供者和網(wǎng)絡(luò)之間沒有提供認(rèn)證的缺點(diǎn)，本發(fā)明的目的在于為各種網(wǎng)絡(luò)中的業(yè)務(wù)簽約者SS和業(yè)務(wù)提供者SP業(yè)務(wù)通信前需要進(jìn)行的與網(wǎng)絡(luò)的互認(rèn)證過程提供一種通用、簡單的認(rèn)證方法，以擴(kuò)大端到端認(rèn)證框架的適用范圍。
本發(fā)明所述技術(shù)方案如下一種業(yè)務(wù)實(shí)體認(rèn)證方法，所述方法包括以下步驟步驟A業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請求，所述認(rèn)證請求內(nèi)容包括所述業(yè)務(wù)實(shí)體的身份標(biāo)識；步驟B所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，根據(jù)本地策略選擇一種認(rèn)證方式，并向所述業(yè)務(wù)實(shí)體發(fā)送含有所述認(rèn)證方式認(rèn)證初始化消息；步驟C所述業(yè)務(wù)實(shí)體與實(shí)體認(rèn)證中心間基于所選認(rèn)證方式進(jìn)行認(rèn)證交互。
所述步驟B中根據(jù)本地策略選擇一種認(rèn)證方式的步驟具體包括步驟B1所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，根據(jù)所述業(yè)務(wù)實(shí)體的身份標(biāo)識查找實(shí)體簽約數(shù)據(jù)庫，得到簽約信息中保存的所述業(yè)務(wù)實(shí)體所支持的認(rèn)證方式信息；步驟B2所述實(shí)體認(rèn)證中心協(xié)商所述業(yè)務(wù)實(shí)體和網(wǎng)絡(luò)所支持的認(rèn)證方式，根據(jù)本地策略選擇一種認(rèn)證方式。
所述步驟A中所述認(rèn)證請求內(nèi)容還包括所述業(yè)務(wù)實(shí)體所支持的認(rèn)證方式信息；相應(yīng)地，所述步驟B中根據(jù)本地策略選擇一種認(rèn)證方式的步驟具體包括步驟B1’所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，得到所述業(yè)務(wù)實(shí)體所支持的認(rèn)證方式；步驟B2’所述實(shí)體認(rèn)證中心協(xié)商所述業(yè)務(wù)實(shí)體和網(wǎng)絡(luò)所支持的認(rèn)證方式，并根據(jù)本地策略選擇一種認(rèn)證方式。
所述步驟A中所述認(rèn)證請求內(nèi)容還包括所述業(yè)務(wù)實(shí)體的安全等級信息；相應(yīng)地，所述步驟B進(jìn)一步包括所述實(shí)體認(rèn)證中心綜合業(yè)務(wù)實(shí)體、網(wǎng)絡(luò)對認(rèn)證方式的支持情況以及安全等級信息，采用本地策略選擇一種安全等級及相應(yīng)的認(rèn)證方式。
所述業(yè)務(wù)實(shí)體可以針對需要進(jìn)行的業(yè)務(wù)類型查找本地保存的業(yè)務(wù)安全等級列表選擇相應(yīng)的安全等級或設(shè)定安全等級。
所述安全等級信息為業(yè)務(wù)提供者的身份標(biāo)識，相應(yīng)地，所述步驟B中所述實(shí)體認(rèn)證中心收到所述業(yè)務(wù)提供者的身份標(biāo)識后，根據(jù)所述身份標(biāo)識得到該業(yè)務(wù)提供者相應(yīng)的業(yè)務(wù)類型，并根據(jù)所述業(yè)務(wù)類型查找安全等級列表選擇相應(yīng)的安全等級。
如果所述認(rèn)證交互由所述實(shí)體認(rèn)證中心側(cè)發(fā)起，所述認(rèn)證初始化消息中還包括所述認(rèn)證交互的第一條認(rèn)證消息內(nèi)容。
所述步驟C具體包括步驟C1所述業(yè)務(wù)實(shí)體獲得認(rèn)證方式后，所述業(yè)務(wù)實(shí)體與所述實(shí)體認(rèn)證中心間進(jìn)行基于所選認(rèn)證方式的認(rèn)證交互消息；步驟C2認(rèn)證結(jié)束后，業(yè)務(wù)實(shí)體與實(shí)體認(rèn)證中心得到共享密鑰材料，并且實(shí)體認(rèn)證中心為業(yè)務(wù)實(shí)體分配臨時(shí)身份標(biāo)識，所述臨時(shí)身份標(biāo)識與共享密鑰材料關(guān)聯(lián)保存。
當(dāng)網(wǎng)絡(luò)與業(yè)務(wù)實(shí)體都只支持同一種認(rèn)證方式時(shí)，所述本地策略為無需認(rèn)證協(xié)商，雙方直接采用此認(rèn)證方式進(jìn)行互認(rèn)證。
所述步驟A中認(rèn)證請求為HTTP Digest認(rèn)證請求，所述步驟B中認(rèn)證初始化消息為HTTP的401消息。
所述認(rèn)證方式包括但并不限于AKA認(rèn)證方式、基于SIM的認(rèn)證方式、基于CAVE的認(rèn)證方式、基于AAA的認(rèn)證方式、TLS握手協(xié)議、DH交換、公鑰證書認(rèn)證和生物認(rèn)證。
本發(fā)明還提供了一種業(yè)務(wù)實(shí)體認(rèn)證裝置，所述裝置包括認(rèn)證請求發(fā)送模塊，協(xié)商模塊和認(rèn)證交互模塊；所述認(rèn)證請求發(fā)送模塊用于業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請求，所述認(rèn)證請求內(nèi)容包括所述業(yè)務(wù)實(shí)體的身份標(biāo)識；所述協(xié)商模塊用于所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，根據(jù)本地策略選擇一種認(rèn)證方式，并向所述業(yè)務(wù)實(shí)體發(fā)送含有所述認(rèn)證方式認(rèn)證初始化消息；所述認(rèn)證交互模塊用于所述業(yè)務(wù)實(shí)體與實(shí)體認(rèn)證中心間基于所選認(rèn)證方式進(jìn)行認(rèn)證交互。
本發(fā)明的有益效果是1、本發(fā)明所述認(rèn)證方法為各種網(wǎng)絡(luò)中的業(yè)務(wù)簽約者SS和業(yè)務(wù)提供者SP業(yè)務(wù)通信前需要進(jìn)行的與網(wǎng)絡(luò)的互認(rèn)證過程提供一種可協(xié)商的、通用的認(rèn)證方法，以擴(kuò)大端到端認(rèn)證框架的適用范圍。
2、本發(fā)明所述認(rèn)證方法提高了該端到端認(rèn)證框架的兼容性，使其能夠兼容3GPP和3GPP2兩種標(biāo)準(zhǔn)中的通用鑒權(quán)框架。
3、本發(fā)明所述認(rèn)證方法在協(xié)商認(rèn)證方式時(shí)還加入了業(yè)務(wù)安全等級需求作為協(xié)商需要考慮的因素之一，既提高的資源利用率又使得高安全等級需求的業(yè)務(wù)有了較高的安全保障。
圖1是現(xiàn)有技術(shù)中3GPP中的通用鑒權(quán)框架圖；圖2是現(xiàn)有技術(shù)中3GPP2中的通用鑒權(quán)框架圖；圖3是本發(fā)明所述端到端通信認(rèn)證的框架圖；圖4是本發(fā)明所述業(yè)務(wù)實(shí)體認(rèn)證方法的流程圖；圖5是本發(fā)明所述業(yè)務(wù)實(shí)體在3GPP標(biāo)準(zhǔn)規(guī)范的無線網(wǎng)絡(luò)中認(rèn)證方法的流程圖；圖6是本發(fā)明所述業(yè)務(wù)實(shí)體在3GPP2標(biāo)準(zhǔn)規(guī)范的無線網(wǎng)絡(luò)中認(rèn)證方法的流程圖；圖7是本發(fā)明所述認(rèn)證方法中SP為銀行時(shí)與實(shí)體認(rèn)證中心互認(rèn)證的流程圖；圖8是本發(fā)明所述認(rèn)證裝置的結(jié)構(gòu)圖。
具體實(shí)施方案下面將參照相應(yīng)的附圖和實(shí)施例對本發(fā)明作進(jìn)一步說明，但并不作為對本發(fā)明的限定。
參見圖3，圖中涉及到的網(wǎng)絡(luò)元素除了2種業(yè)務(wù)實(shí)體SS(ServiceSubscriber-網(wǎng)絡(luò)簽約者)(101)、SP(Service Provider-網(wǎng)絡(luò)提供者)102以外，在運(yùn)營商網(wǎng)絡(luò)中，還應(yīng)該存在一個(gè)EAC(Entity Authentication Center-實(shí)體認(rèn)證中心)(103)和一個(gè)ESD(Entity Subscription Database-實(shí)體簽約信息數(shù)據(jù)庫)(104)。在本發(fā)明中，業(yè)務(wù)實(shí)體可以是業(yè)務(wù)簽約者(SS)，也可以是業(yè)務(wù)提供者(SP)。其中SS分別相當(dāng)于3GPP通用鑒權(quán)框架中的用戶或3GPP2通用鑒權(quán)框架中的MN；SP分別相當(dāng)于3GPP通用鑒權(quán)框架或3GPP2通用鑒權(quán)框架中的NAF；EAC分別相當(dāng)于3GPP通用鑒權(quán)框架或3GPP2通用鑒權(quán)框架中的BSF。
實(shí)施例1參見圖4，本發(fā)明所述的認(rèn)證方法描述如下步驟401業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心(EAC-Entity AuthenticationCenter)發(fā)送認(rèn)證請求，請求消息中可以攜帶業(yè)務(wù)實(shí)體的身份標(biāo)識信息，安全等級信息，業(yè)務(wù)實(shí)體所支持的認(rèn)證方式信息(如果與網(wǎng)絡(luò)的簽約信息中保存有該業(yè)務(wù)實(shí)體所支持的認(rèn)證方式信息，該項(xiàng)可以不攜帶)等。其中身份信息可以包含私有身份標(biāo)識PID，或公開身份標(biāo)識UID等；對于安全等級的選取，可以考慮以下幾種情況(1)業(yè)務(wù)實(shí)體可以針對需要進(jìn)行的業(yè)務(wù)類型查找本地保存的業(yè)務(wù)安全等級列表選擇相應(yīng)的安全等級；(2)當(dāng)業(yè)務(wù)實(shí)體本地沒有保存安全等級列表時(shí)，它可以根據(jù)主觀需要手動(dòng)選擇安全等級；(3)業(yè)務(wù)實(shí)體也可以不選擇安全等級而只是將相應(yīng)業(yè)務(wù)提供者的UID發(fā)送給EAC，UID能夠標(biāo)識出該業(yè)務(wù)提供者提供的業(yè)務(wù)類型，然后EAC根據(jù)業(yè)務(wù)類型查找安全等級列表選擇相應(yīng)的安全等級。
步驟402EAC收到認(rèn)證請求后，根據(jù)身份標(biāo)識查找ESD中保存的簽約信息，并綜合業(yè)務(wù)實(shí)體、網(wǎng)絡(luò)對認(rèn)證方式的支持情況以及安全等級，采用本地策略選擇一種認(rèn)證方式b。所支持的認(rèn)證方式包括AKA，基于SIM的認(rèn)證，基于CAVE的認(rèn)證方式，基于AAA的認(rèn)證方式，TLS握手協(xié)議，DH交換，公鑰證書認(rèn)證，生物認(rèn)證等。
當(dāng)網(wǎng)絡(luò)與業(yè)務(wù)實(shí)體都只支持一種認(rèn)證方式時(shí)，無需認(rèn)證協(xié)商，雙方直接采用此認(rèn)證方式進(jìn)行互認(rèn)證。
EAC選擇安全等級時(shí)可以結(jié)合業(yè)務(wù)的安全等級需求也可以不結(jié)合，即安全等級這一條件對于認(rèn)證協(xié)商過程是可選的。
步驟403EAC向業(yè)務(wù)實(shí)體發(fā)送認(rèn)證初始化消息，該消息中攜帶所選認(rèn)證方式的標(biāo)號，安全等級(如果在步驟402的協(xié)商過程中考慮安全等級，則該安全等級應(yīng)不低于業(yè)務(wù)實(shí)體所選擇的安全等級)等。
如果后續(xù)的認(rèn)證交互過程由EAC側(cè)發(fā)起，則該認(rèn)證初始化消息還應(yīng)包括基于此認(rèn)證方式的第一條認(rèn)證消息所承載的信息。
上述第一條認(rèn)證消息的內(nèi)容對于AKA認(rèn)證來說是認(rèn)證向量，對TLS認(rèn)證方式就是Hello Request。
步驟404業(yè)務(wù)實(shí)體獲知認(rèn)證方式。如果后續(xù)的認(rèn)證由實(shí)體側(cè)發(fā)起，則該業(yè)務(wù)實(shí)體計(jì)算認(rèn)證信息；如果認(rèn)證由EAC側(cè)發(fā)起，業(yè)務(wù)實(shí)體收到了相關(guān)認(rèn)證信息，那么它將計(jì)算響應(yīng)值。
步驟405業(yè)務(wù)實(shí)體與EAC間進(jìn)行基于所選認(rèn)證方式的認(rèn)證交互過程。
步驟406認(rèn)證結(jié)束后，業(yè)務(wù)實(shí)體與EAC共享了密鑰材料，并且EAC為業(yè)務(wù)實(shí)體分配臨時(shí)身份標(biāo)識ISR-ID或IAC-ID該標(biāo)識與共享密鑰材料關(guān)聯(lián)保存，可以作為查找密鑰材料的一個(gè)索引，或者是一個(gè)安全連接的Session ID。
實(shí)施例2參見圖5，本例中業(yè)務(wù)實(shí)體為SS，當(dāng)SS為3GPP網(wǎng)絡(luò)中的移動(dòng)終端，即圖中的UE，且只支持AKA認(rèn)證時(shí)，本發(fā)明所述的方法如下步驟501UE向EAC發(fā)送HTTP Digest認(rèn)證請求，消息中攜帶身份標(biāo)識；步驟502由于3GPP和UE都只支持AKA方式，因此雙方不需要協(xié)商認(rèn)證方式，直接采用AKA方式認(rèn)證，EAC到ESD獲取該用戶的認(rèn)證向量(RAND，AUTN，RES，CK，IK)；步驟503EAC在HTTP的401消息(包含Digest AKA challenge)中發(fā)送RAND和AUTN給UE；步驟504UE計(jì)算并檢驗(yàn)AUTN的正確性，以確認(rèn)challenge消息是否來自一個(gè)被授權(quán)的網(wǎng)絡(luò)，同時(shí)UE計(jì)算CK、IK和RES；步驟505UE發(fā)送HTTP request消息給EAC，包含有Digest AKA response，由RES計(jì)算摘要值；步驟506EAC驗(yàn)證摘要值的正確性，以認(rèn)證UE的合法性；步驟507EAC生成密鑰材料Ks＝CK||IK，以及ISR-ID(該ISR-ID生成方法以及格式與3GPP通用鑒權(quán)框架中的B-TID相同)；步驟508EAC發(fā)送200OK消息，表示認(rèn)證成功結(jié)束，消息中包含密鑰材料的有效期以及ISR-ID，并由Ks加密傳送給UE；步驟509UE也生成同樣的Ks＝CK||IK，然后解密獲得ISR-ID以及有效期，并和有效期認(rèn)證方式等關(guān)聯(lián)保存在本地。
實(shí)施例3本例中業(yè)務(wù)實(shí)體為SS，當(dāng)SS為一移動(dòng)終端UE，且支持AKA認(rèn)證、證書認(rèn)證等認(rèn)證方法，而網(wǎng)絡(luò)側(cè)是3GPP2的網(wǎng)絡(luò)支持AKA認(rèn)證、基于CAVE的認(rèn)證方式以及基于MN-AAA的認(rèn)證方式時(shí)，參見圖6，本發(fā)明所述的方法如下步驟601UE向EAC發(fā)送認(rèn)證請求，消息中攜帶身份標(biāo)識，支持的認(rèn)證方式，如AKA認(rèn)證、證書認(rèn)證；步驟602EAC根據(jù)UE的身份標(biāo)識到ESD查找其簽約信息，再根據(jù)自身所支持的認(rèn)證方式類型，如支持AKA認(rèn)證、基于CAVE的認(rèn)證方式以及基于MN-AAA的認(rèn)證方式，采用本地策略最后確定雙方采用AKA方式進(jìn)行認(rèn)證；EAC到ESD獲取該用戶的認(rèn)證向量(RAND，AUTN，RES，CK，IK)；步驟603EAC在HTTP的401消息(包含Digest AKA challenge)中發(fā)送RAND和AUTN給UE，并將認(rèn)證方式標(biāo)識放在payload信息中；步驟604UE計(jì)算并檢驗(yàn)AUTN的正確性，以確認(rèn)challenge消息是否來自一個(gè)被授權(quán)的網(wǎng)絡(luò)，同時(shí)UE計(jì)算CK、IK和RES；步驟605UE發(fā)送HTTP request消息給EAC，包含有Digest AKA response，由RES計(jì)算摘要值；步驟606EAC驗(yàn)證摘要值的正確性，以認(rèn)證UE的合法性；步驟607EAC生成密鑰材料Ks＝CK||IK，以及ISR-ID(該ISR-ID生成方法以及格式與3GPP2通用鑒權(quán)框架中的B-TID相同)；步驟608EAC發(fā)送200OK消息，表示認(rèn)證成功結(jié)束，消息中包含密鑰材料的有效期以及ISR-ID，并由Ks加密傳送給UE。
步驟609UE也生成同樣的Ks＝CK||IK，然后解密獲得ISR-ID以及有效期，并和有效期認(rèn)證方式等關(guān)聯(lián)保存在本地。
如果UE也支持基于CAVE的認(rèn)證方式，而且EAC收到認(rèn)證請求后，根據(jù)身法標(biāo)識查找簽約信息，并結(jié)合自身支持的認(rèn)證方式類型，采用本地策最后確定基于CAVE的認(rèn)證方式進(jìn)行互認(rèn)證，則后面的認(rèn)證流程與3GPP2通用鑒權(quán)框架中的基于CAVE的認(rèn)證流程一樣。AAA認(rèn)證方式時(shí)也同理可以使用本發(fā)明方案的統(tǒng)一框架。
實(shí)施例4本例中業(yè)務(wù)實(shí)體為銀行SP，當(dāng)銀行SP欲向UE提供業(yè)務(wù)手機(jī)銀行業(yè)務(wù)前，首先需要與EAC互認(rèn)證生成共享密鑰材料，并建立安全連接，參見圖7，本發(fā)明所述的方法如下步驟701SP向EAC發(fā)送認(rèn)證請求，所述請求消息中攜帶SP的公開身份標(biāo)識UID；
步驟702EAC根據(jù)公開身份標(biāo)識查找SP的簽約信息，確認(rèn)SP有權(quán)提供此項(xiàng)業(yè)務(wù)后，獲取該SP的認(rèn)證能力信息，即該SP所支持的認(rèn)證方式，如證書、證書TLS認(rèn)、基于預(yù)共享密鑰的TLS認(rèn)證等；然后，EAC查找業(yè)務(wù)安全等級列表，確認(rèn)該手機(jī)銀行業(yè)務(wù)屬于高安全等級，并且查找認(rèn)證安全等級列表，找到符合高安全等級的網(wǎng)絡(luò)支持的認(rèn)證方式有HTTP Digest AKA，證書TLS認(rèn)證，最后匹配SP所支持的認(rèn)證方式，確定采用證書TLS進(jìn)行互認(rèn)證；步驟703EAC向SP發(fā)起Hello Request，并且攜帶認(rèn)證方式標(biāo)識(證書TLS認(rèn)證)，以及安全等級標(biāo)識；步驟704SP獲知認(rèn)證方式為證書TLS，查找本地有無Session IDIAC-ID，即以前已經(jīng)通過EAC的證書TLS認(rèn)證建立了TLS安全通道并且還在有效期內(nèi)，Session ID可以作為該TLS安全通道的索引；步驟705SP向EAC發(fā)送Client Hello消息。如果SP沒有保存有效的Session ID，該消息的Session ID字段為空；如果保存有有效的Session IDIAC-ID，該消息的Session ID字段為該IAC-ID；步驟706EAC收到Client Hello消息后，查看Session ID字段是否為空，如果不為空，且能夠匹配到相關(guān)聯(lián)的安全連接信息，EAC直接發(fā)送Finished消息驗(yàn)證該安全連接的認(rèn)證結(jié)果和共享密鑰材料是否可用。SP驗(yàn)證Finished消息中的參數(shù)正確后，返回Finished消息。EAC驗(yàn)證該Finished消息參數(shù)正確后，雙方重用該安全連接。
如果Session ID字段為空或上述Finished消息有誤，則EAC根據(jù)本地策略配置消息中的參數(shù)，依次發(fā)送Server certificate消息、ServerKeyExchenge消息(可選)、CertificateRequest消息。
最后，EAC返回ServerHelloDone消息，表示ServerHello以及相關(guān)消息發(fā)送完畢；步驟707在收到ServerHelloDone消息后，返回Certificate消息，然后發(fā)送ClientKeyExchange消息，通過這條消息雙方獲得了共享秘密參數(shù)；然后，發(fā)送CertifiicateVerify消息，便于EAC清楚地驗(yàn)證該SP的證書；
最后，在ChangeCipherSpec消息后立即發(fā)送Finished消息，用于正式密鑰交換和驗(yàn)證過程的成功；步驟708EAC驗(yàn)證SP的Finished消息中的信息是否正確，如果不正確中止當(dāng)前握手過程。如果正確，返回Finished消息。
如果，SP驗(yàn)證Finished消息中的信息正確，那么雙方認(rèn)證和密鑰交換過程成功結(jié)束。
本實(shí)例提供了3GPP/3GPP2網(wǎng)絡(luò)認(rèn)證NAF的統(tǒng)一化過程方案，同樣是基于本發(fā)明方案的統(tǒng)一框架。
參見圖8，本發(fā)明還提供了一種實(shí)體認(rèn)證裝置，所述裝置包括認(rèn)證請求發(fā)送模塊，協(xié)商模塊和認(rèn)證交互模塊；所述認(rèn)證請求發(fā)送模塊用于業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請求，所述認(rèn)證請求的內(nèi)容包括所述業(yè)務(wù)實(shí)體的身份標(biāo)識；所述協(xié)商模塊用于所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，根據(jù)本地策略選擇一種認(rèn)證方式，并向所述業(yè)務(wù)實(shí)體發(fā)送認(rèn)證初始化消息；所述認(rèn)證交互模塊用于所述業(yè)務(wù)實(shí)體與實(shí)體認(rèn)證中心間基于所選認(rèn)證方式進(jìn)行認(rèn)證交互。
以上只是本發(fā)明的優(yōu)選實(shí)施方式進(jìn)行了描述，本領(lǐng)域的技術(shù)人員在本發(fā)明技術(shù)的方案范圍內(nèi)，進(jìn)行的通常變化和替換，都應(yīng)包含在本發(fā)明的保護(hù)范圍內(nèi)。
權(quán)利要求
1.一種業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述方法包括以下步驟步驟A業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請求，所述認(rèn)證請求內(nèi)容包括所述業(yè)務(wù)實(shí)體的身份標(biāo)識；步驟B所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，根據(jù)本地策略選擇一種認(rèn)證方式，并向所述業(yè)務(wù)實(shí)體發(fā)送含有所述認(rèn)證方式認(rèn)證初始化消息；步驟C所述業(yè)務(wù)實(shí)體與實(shí)體認(rèn)證中心間基于所選認(rèn)證方式進(jìn)行認(rèn)證交互。
2.如權(quán)利要求1所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述步驟B中根據(jù)本地策略選擇一種認(rèn)證方式的步驟具體包括步驟B1所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，根據(jù)所述業(yè)務(wù)實(shí)體的身份標(biāo)識查找實(shí)體簽約數(shù)據(jù)庫，得到簽約信息中保存的所述業(yè)務(wù)實(shí)體所支持的認(rèn)證方式信息；步驟B2所述實(shí)體認(rèn)證中心協(xié)商所述業(yè)務(wù)實(shí)體和網(wǎng)絡(luò)所支持的認(rèn)證方式，根據(jù)本地策略選擇一種認(rèn)證方式。
3.如權(quán)利要求1所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述步驟A中所述認(rèn)證請求內(nèi)容還包括所述業(yè)務(wù)實(shí)體所支持的認(rèn)證方式信息；相應(yīng)地，所述步驟B中根據(jù)本地策略選擇一種認(rèn)證方式的步驟具體包括步驟B1’所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，得到所述業(yè)務(wù)實(shí)體所支持的認(rèn)證方式；步驟B2’所述實(shí)體認(rèn)證中心協(xié)商所述業(yè)務(wù)實(shí)體和網(wǎng)絡(luò)所支持的認(rèn)證方式，并根據(jù)本地策略選擇一種認(rèn)證方式。
4.如權(quán)利要求1所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述步驟A中所述認(rèn)證請求內(nèi)容還包括所述業(yè)務(wù)實(shí)體的安全等級信息；相應(yīng)地，所述步驟B進(jìn)一步包括所述實(shí)體認(rèn)證中心綜合業(yè)務(wù)實(shí)體、網(wǎng)絡(luò)對認(rèn)證方式的支持情況以及安全等級信息，采用本地策略選擇一種安全等級及相應(yīng)的認(rèn)證方式。
5.如權(quán)利要求4所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述業(yè)務(wù)實(shí)體可以針對需要進(jìn)行的業(yè)務(wù)類型查找本地保存的業(yè)務(wù)安全等級列表選擇相應(yīng)的安全等級或設(shè)定安全等級。
6.如權(quán)利要求4所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述安全等級信息為業(yè)務(wù)提供者的身份標(biāo)識，相應(yīng)地，所述步驟B中所述實(shí)體認(rèn)證中心收到所述業(yè)務(wù)提供者的身份標(biāo)識后，根據(jù)所述身份標(biāo)識得到該業(yè)務(wù)提供者相應(yīng)的業(yè)務(wù)類型，并根據(jù)所述業(yè)務(wù)類型查找安全等級列表選擇相應(yīng)的安全等級。
7.如權(quán)利要求1所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，如果所述認(rèn)證交互由所述實(shí)體認(rèn)證中心側(cè)發(fā)起，所述認(rèn)證初始化消息中還包括所述認(rèn)證交互的第一條認(rèn)證消息內(nèi)容。
8.如權(quán)利要求1所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述步驟C具體包括步驟C1所述業(yè)務(wù)實(shí)體獲得認(rèn)證方式后，所述業(yè)務(wù)實(shí)體與所述實(shí)體認(rèn)證中心間進(jìn)行基于所選認(rèn)證方式的認(rèn)證交互消息；步驟C2認(rèn)證結(jié)束后，業(yè)務(wù)實(shí)體與實(shí)體認(rèn)證中心得到共享密鑰材料，并且實(shí)體認(rèn)證中心為業(yè)務(wù)實(shí)體分配臨時(shí)身份標(biāo)識，所述臨時(shí)身份標(biāo)識與共享密鑰材料關(guān)聯(lián)保存。
9.如權(quán)利要求1所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，當(dāng)網(wǎng)絡(luò)與業(yè)務(wù)實(shí)體都只支持同一種認(rèn)證方式時(shí)，所述本地策略為無需認(rèn)證協(xié)商，雙方直接采用此認(rèn)證方式進(jìn)行互認(rèn)證。
10.如權(quán)利要求1所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述步驟A中認(rèn)證請求為HTTP Digest認(rèn)證請求，所述步驟B中認(rèn)證初始化消息為HTTP的401消息。
11.如權(quán)利要求1所述的業(yè)務(wù)實(shí)體認(rèn)證方法，其特征在于，所述認(rèn)證方式包括但并不限于AKA認(rèn)證方式、基于SIM的認(rèn)證方式、基于CAVE的認(rèn)證方式、基于AAA的認(rèn)證方式、TLS握手協(xié)議、DH交換、公鑰證書認(rèn)證和生物認(rèn)證。
12.一種業(yè)務(wù)實(shí)體認(rèn)證裝置，其特征在于，所述裝置包括認(rèn)證請求發(fā)送模塊，協(xié)商模塊和認(rèn)證交互模塊；所述認(rèn)證請求發(fā)送模塊用于業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請求，所述認(rèn)證請求內(nèi)容包括所述業(yè)務(wù)實(shí)體的身份標(biāo)識；所述協(xié)商模塊用于所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，根據(jù)本地策略選擇一種認(rèn)證方式，并向所述業(yè)務(wù)實(shí)體發(fā)送含有所述認(rèn)證方式認(rèn)證初始化消息；所述認(rèn)證交互模塊用于所述業(yè)務(wù)實(shí)體與實(shí)體認(rèn)證中心間基于所選認(rèn)證方式進(jìn)行認(rèn)證交互。
全文摘要
本發(fā)明提供了一種業(yè)務(wù)實(shí)體認(rèn)證方法和裝置，涉及網(wǎng)絡(luò)通信領(lǐng)域。為了克服現(xiàn)有技術(shù)中存在鑒權(quán)框架不能適用于多種網(wǎng)絡(luò)，并且業(yè)務(wù)提供者和網(wǎng)絡(luò)之間沒有提供認(rèn)證的不足，本發(fā)明所述方法包括業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請求，所述實(shí)體認(rèn)證中心收到認(rèn)證請求后，根據(jù)本地策略選擇一種認(rèn)證方式，所述業(yè)務(wù)實(shí)體與實(shí)體認(rèn)證中心間基于所選認(rèn)證方式進(jìn)行認(rèn)證交互的步驟。本發(fā)明還提供了一種業(yè)務(wù)實(shí)體認(rèn)證裝置，包括認(rèn)證請求發(fā)送模塊，協(xié)商模塊和認(rèn)證交互模塊。本發(fā)明所述技術(shù)方案提供了一種可協(xié)商的、通用的認(rèn)證方法，提高了端到端認(rèn)證框架的兼容性。
文檔編號H04L9/32GK101052032SQ20061007490
公開日2007年10月10日 申請日期2006年4月4日 優(yōu)先權(quán)日2006年4月4日
發(fā)明者范絮妍, 位繼偉, 李超 申請人:華為技術(shù)有限公司