專利名稱：一種端到端通信認(rèn)證的方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明屬于網(wǎng)絡(luò)安全領(lǐng)域，特別涉及一種端到端通信認(rèn)證的方法及裝置。
背景技術(shù)：
端到端通信認(rèn)證框架是一種適用于不同移動(dòng)網(wǎng)絡(luò)標(biāo)準(zhǔn)的通用鑒權(quán)框架，其作用在于為不同類型的實(shí)體之間建立相互信任關(guān)系。參見(jiàn)圖1，該框架涉及到的網(wǎng)絡(luò)元素除了3種業(yè)務(wù)實(shí)體業(yè)務(wù)簽約者(SS-Service Provider)(101)、既是業(yè)務(wù)簽約者又是業(yè)務(wù)提供者(SSP-Service Subscriber and Provider)(102)、業(yè)務(wù)提供者(SP-Service Provider)(103)以外，在運(yùn)營(yíng)商網(wǎng)絡(luò)中，還應(yīng)該存在一個(gè)實(shí)體認(rèn)證中心(EAC-Entity Authentication Center)(104)和一個(gè)實(shí)體簽約信息數(shù)據(jù)庫(kù)(ESD-Entity Subscription Database)(105)。
業(yè)務(wù)提供者在能夠向其它實(shí)體提供業(yè)務(wù)，或者業(yè)務(wù)簽約者向其它實(shí)體請(qǐng)求業(yè)務(wù)之前，應(yīng)該首先已經(jīng)與網(wǎng)絡(luò)存在簽約關(guān)系，并將簽約信息存放于ESD中。
網(wǎng)絡(luò)中每個(gè)業(yè)務(wù)簽約者與業(yè)務(wù)提供者進(jìn)行通信之前，業(yè)務(wù)實(shí)體需要先到EAC協(xié)商認(rèn)證方式，并完成對(duì)身份的認(rèn)證過(guò)程。
認(rèn)證方式的協(xié)商過(guò)程應(yīng)該由業(yè)務(wù)實(shí)體發(fā)起，并在請(qǐng)求消息攜帶自身身份標(biāo)識(shí)，以及業(yè)務(wù)的安全等級(jí)需求。EAC根據(jù)安全等級(jí)、網(wǎng)絡(luò)支持情況和實(shí)體簽約信息，選擇一種認(rèn)證方法，并將相應(yīng)信息返回給認(rèn)證請(qǐng)求者。其中業(yè)務(wù)的安全等級(jí)不同所選擇的認(rèn)證方式也不同。請(qǐng)求者再發(fā)確認(rèn)信息表示協(xié)商過(guò)程結(jié)束。
接下來(lái)實(shí)體與EAC按照協(xié)商的方式進(jìn)行認(rèn)證。該認(rèn)證應(yīng)該是雙向的。認(rèn)證結(jié)束后，認(rèn)證請(qǐng)求實(shí)體和EAC應(yīng)該生成共享的密鑰材料，并且EAC將會(huì)根據(jù)認(rèn)證請(qǐng)求實(shí)體的簽約信息情況給其分配臨時(shí)身份標(biāo)識(shí)以及相應(yīng)的有效期1)如果該認(rèn)證請(qǐng)求實(shí)體是SS，則EAC將向其分配一個(gè)中間業(yè)務(wù)請(qǐng)求標(biāo)識(shí)(ISR-ID-Interim Service RequestIdentifier)。2)如果該認(rèn)證請(qǐng)求實(shí)體是SSP，則EAC將向其分配一個(gè)中間業(yè)務(wù)查詢標(biāo)識(shí)(IAC-ID-Interim Authentication CheckIdentifier)。
最后EAC將業(yè)務(wù)實(shí)體的臨時(shí)身份標(biāo)識(shí)以及有效期發(fā)送給請(qǐng)求認(rèn)證的業(yè)務(wù)實(shí)體，此后該業(yè)務(wù)實(shí)體與EAC之間的通信都可以采用認(rèn)證過(guò)程生成的業(yè)務(wù)實(shí)體與EAC間的共享密鑰材料進(jìn)行保護(hù)。
在業(yè)務(wù)簽約者完成到EAC的認(rèn)證過(guò)程后，便可向業(yè)務(wù)提供者請(qǐng)求業(yè)務(wù)。SP或SSP收到請(qǐng)求以后，如果已經(jīng)完成到EAC的認(rèn)證過(guò)程并獲得有效的IAC-ID，便可向EAC查詢業(yè)務(wù)簽約者的認(rèn)證情況。否則，首先到EAC進(jìn)行認(rèn)證以及密鑰協(xié)商過(guò)程后，再向EAC請(qǐng)求查詢業(yè)務(wù)簽約者的認(rèn)證情況。并在查詢請(qǐng)求消息攜帶業(yè)務(wù)簽約者的ISR-ID以及自身的IAC-ID。
EAC收到查詢請(qǐng)求后，首先根據(jù)業(yè)務(wù)簽約者的標(biāo)識(shí)信息以及業(yè)務(wù)提供者的標(biāo)識(shí)查詢二者有沒(méi)有相應(yīng)的權(quán)限，然后根據(jù)二者的相關(guān)信息，利用SS/SSP到EAC協(xié)商的Ks為二者計(jì)算一個(gè)用于保護(hù)業(yè)務(wù)簽約者和提供者之間業(yè)務(wù)通信的衍生密鑰。并發(fā)送給業(yè)務(wù)提供者。
同時(shí)，業(yè)務(wù)簽約者也由相同的參數(shù)以及算法計(jì)算出衍生密鑰。
當(dāng)SS和SP具有共享的衍生密鑰后，需要利用衍生密鑰進(jìn)行雙方間的互認(rèn)證，并進(jìn)一步生成保護(hù)本次通信安全的會(huì)話密鑰Kr-SS-SP。
業(yè)務(wù)實(shí)體與EAC之間認(rèn)證所建立的信任關(guān)系存在一個(gè)有效期。有效期快要過(guò)期或已經(jīng)過(guò)期，業(yè)務(wù)實(shí)體需要到EAC之間進(jìn)行重認(rèn)證過(guò)程，建立新的信任關(guān)系。
現(xiàn)有技術(shù)有以下缺點(diǎn)1.整個(gè)認(rèn)證過(guò)程分為不同的認(rèn)證階段，在每個(gè)認(rèn)證階段都需要進(jìn)行認(rèn)證方法的協(xié)商，使整個(gè)認(rèn)證過(guò)程的消息交互有重復(fù)、不合理，認(rèn)證階段劃分過(guò)于僵化；2.在某些情況下，SS和SP可以直接認(rèn)證并建立安全連接，因此并不需要進(jìn)行SS和EAC及SP和EAC的認(rèn)證，而現(xiàn)有技術(shù)中的框架每個(gè)認(rèn)證階段中的認(rèn)證方法定義不具有選擇性，必須經(jīng)過(guò)認(rèn)證；3.不能很好兼容現(xiàn)有各種機(jī)制，例如，如果在3GPP場(chǎng)景下使用，實(shí)現(xiàn)起來(lái)比較復(fù)雜。

發(fā)明內(nèi)容
為了解決現(xiàn)有技術(shù)中認(rèn)證各步驟劃分過(guò)于僵化且認(rèn)證過(guò)程不靈活，認(rèn)證步驟的交互消息有重復(fù)、不合理，不能以統(tǒng)一的方式處理各種認(rèn)證方法，不能很好兼容現(xiàn)有各種機(jī)制的問(wèn)題，本發(fā)明提供了一種端到端通信認(rèn)證方法及裝置。
本發(fā)明所述方案如下一種端到端通信認(rèn)證方法，根據(jù)具體業(yè)務(wù)定義認(rèn)證模式，所述方法包括以下步驟步驟A業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請(qǐng)求信息，所述請(qǐng)求信息包括業(yè)務(wù)實(shí)體的身份標(biāo)識(shí)、認(rèn)證能力標(biāo)識(shí)和業(yè)務(wù)類型；步驟B所述實(shí)體認(rèn)證中心收到所述認(rèn)證請(qǐng)求后，選擇認(rèn)證模式并發(fā)送給業(yè)務(wù)實(shí)體；步驟C業(yè)務(wù)實(shí)體根據(jù)所述選擇的認(rèn)證模式進(jìn)行認(rèn)證。
所述認(rèn)證模式至少設(shè)定以下認(rèn)證方法中的一種業(yè)務(wù)簽約者和認(rèn)證中心的認(rèn)證方法、業(yè)務(wù)提供者和認(rèn)證中心的認(rèn)證方法、業(yè)務(wù)簽約者和業(yè)務(wù)提供者的認(rèn)證方法、會(huì)話密鑰的生成方法。
所述認(rèn)證模式中設(shè)定了所述認(rèn)證方法的選擇策略。
所述選擇策略具體包括所述認(rèn)證方法是否必選。
所述選擇策略具體包括所述認(rèn)證方法是否可協(xié)商。
所述步驟B具體包括步驟B1所述實(shí)體認(rèn)證中心接收所述業(yè)務(wù)實(shí)體發(fā)送的認(rèn)證請(qǐng)求信息；步驟B2所述實(shí)體認(rèn)證中心查詢實(shí)體簽約數(shù)據(jù)庫(kù)，得到雙方的認(rèn)證能力信息；步驟B3所述實(shí)體認(rèn)證中心根據(jù)得到的認(rèn)證能力信息及業(yè)務(wù)類型采用本地策略選擇認(rèn)證模式；步驟B4所述實(shí)體認(rèn)證中心發(fā)送所述選擇的認(rèn)證模式。
所述實(shí)體認(rèn)證中心根據(jù)認(rèn)證模式中認(rèn)證方法的選擇策略及本地策略確定認(rèn)證方法。
所述步驟C具體包括業(yè)務(wù)實(shí)體收到所述選擇的認(rèn)證模式后，根據(jù)所述認(rèn)證模式中的認(rèn)證方法進(jìn)行相應(yīng)的認(rèn)證過(guò)程。
所述步驟C后還包括業(yè)務(wù)實(shí)體間進(jìn)行業(yè)務(wù)通信；如果所述的業(yè)務(wù)實(shí)體間的業(yè)務(wù)通信不止一次，并且認(rèn)證結(jié)果沒(méi)有過(guò)期，則可以重用上次認(rèn)證生成的共享密鑰材料，生成本次業(yè)務(wù)通信的新的會(huì)話密鑰；如果所述認(rèn)證結(jié)果過(guò)期，則重新進(jìn)行認(rèn)證。
所述步驟A之前還包括如果業(yè)務(wù)由業(yè)務(wù)簽約者發(fā)起，則所述業(yè)務(wù)簽約者向所述實(shí)體認(rèn)證中心發(fā)起認(rèn)證請(qǐng)求，如果業(yè)務(wù)由業(yè)務(wù)提供者發(fā)起，則所述業(yè)務(wù)提供者向所述實(shí)體認(rèn)證中心發(fā)起認(rèn)證請(qǐng)求。
本發(fā)明還提供了一種端到端通信認(rèn)證裝置，所述裝置包括發(fā)送模塊，用于業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請(qǐng)求信息；選擇模塊，用于所述實(shí)體認(rèn)證中心收到所述認(rèn)證請(qǐng)求信息后，選擇認(rèn)證模式并發(fā)送給業(yè)務(wù)實(shí)體；認(rèn)證模塊，用于業(yè)務(wù)實(shí)體根據(jù)所述選擇的認(rèn)證模式進(jìn)行認(rèn)證。
本發(fā)明的有益效果是本發(fā)明提供了一種端到端認(rèn)證框架的優(yōu)化使用方法，保留原來(lái)框架的優(yōu)點(diǎn)，同時(shí)進(jìn)行全局優(yōu)化和步驟合并，能夠以統(tǒng)一的方式處理各種認(rèn)證方法。本發(fā)明端到端框架所采用的認(rèn)證模式包含的內(nèi)容更加靈活化、多樣化，并能夠兼容多種現(xiàn)有認(rèn)證模式，而且簡(jiǎn)化了認(rèn)證步驟。


圖1所示為現(xiàn)有技術(shù)中端到端通信認(rèn)證框架示意圖；圖2所示為本發(fā)明所述業(yè)務(wù)簽約者與認(rèn)證中心間的認(rèn)證步驟流程圖；圖3所示為本發(fā)明所述業(yè)務(wù)簽約者與業(yè)務(wù)提供者間的互認(rèn)證流程圖；圖4所示為本發(fā)明所述業(yè)務(wù)簽約者與業(yè)務(wù)提供者重新利用認(rèn)證結(jié)果生成會(huì)話密鑰的流程圖；圖5所示為本發(fā)明所述端到端通信認(rèn)證裝置示意圖。
具體實(shí)施例方式
下面將參照附圖和實(shí)施例對(duì)本發(fā)明進(jìn)行進(jìn)一步說(shuō)明，但并不作為對(duì)本發(fā)明的限定。
本發(fā)明所述端到端通信認(rèn)證方法如下首先定義認(rèn)證模式E2E認(rèn)證模式主要由SS與EAC的認(rèn)證方法決定，有時(shí)也由SS與SP的認(rèn)證方法決定。在認(rèn)證模式中設(shè)定了SS和EAC的認(rèn)證方法、SP和EAC的認(rèn)證方法、SS和SP之間的認(rèn)證方法以及會(huì)話密鑰生成方法；針對(duì)不同的認(rèn)證模式，可以只設(shè)定上述認(rèn)證方法中的一種或者幾種。例如，在SS和SP可以直接認(rèn)證并建立安全連接的情況下，無(wú)需進(jìn)行SS和EAC及SP和EAC的認(rèn)證，則在該模式中只需設(shè)定SS和SP之間的認(rèn)證方法以及會(huì)話密鑰生成方法。
認(rèn)證模式中還設(shè)定了所述每種認(rèn)證方法的選擇策略，其中包括該認(rèn)證方法是否可選或必選，以及該認(rèn)證方法是否可以協(xié)商。
例如E2E的認(rèn)證模式有E2E_3GPP_AKA，E2E_3GPP2_AKA，E2E_3GPP2_CAVE，E2E_WLAN，E2E_3GPP2_MNAAA，E2E_3GPP_WLAN，E2E_Kerberos，E2E_Mediation，E2E_TLS。
模式的定義并不限于這幾種，還可以根據(jù)需要進(jìn)行新的定義。
其中E2E_3GPP_AKA模式定義如下E2E_3GPP_AKA∷＝struct{SS<->EAC認(rèn)證方法 AKA，承載協(xié)議 HTTP DigestSP<->EAC認(rèn)證方法 TLS方式(或IPSec通道等方法)SS<->SP的認(rèn)證方法基本查詢方法承載協(xié)議TLS(或其他)會(huì)話密鑰生成方法是自定義的(或其他，可選)。}E2E_3GPP2_CAVE模式的定義如下E2E_3GPP2_CAVE∷＝struct{SS<->EAC認(rèn)證方法 Authentication based on CAVE，承載協(xié)議 HTTP DigestSP<->EAC認(rèn)證方法 TLS方式(或IPSec通道等方法)SS<->SP的認(rèn)證方法 基本查詢方法承載協(xié)議TLS(或其他)會(huì)話密鑰生成方法是自定義的(或其他，可選)。}E2E_WLAN∷＝struct{SS<->EAC認(rèn)證方法AKA(或SIM)，承載協(xié)議EAP(ExtensibleAuthentication Protocol)可擴(kuò)展認(rèn)證協(xié)議SP<->EAC認(rèn)證方法 TLS方式(或IPSec通道等方法)SS<->SP的認(rèn)證方法 基本查詢方法承載協(xié)議TLS(或其他)會(huì)話密鑰生成方法是自定義的(或其他，可選)。}E2E_Kerberos模式的定義如下E2E_Kerberos∷＝struct{SS<->EAC認(rèn)證方法(可協(xié)商，如AKA，基于CAVE的認(rèn)證，基于證書(shū)的認(rèn)證)SP<->EAC認(rèn)證方法 IPSec通道(或其他，可選)SS<->SP的認(rèn)證方法 Kerberos(必選，可協(xié)商采用那種Kerberos或Kerberos改進(jìn)方案)承載協(xié)議 TCP(或其他)會(huì)話密鑰生成方法 TLS-Krb5(或其他，可選)}E2E_TLS模式的定義如下E2E_TLS∷＝struct{SS<->EAC認(rèn)證方法 無(wú)SP<->EAC認(rèn)證方法 無(wú)SS<->SP的認(rèn)證方法 TLS會(huì)話密鑰生成方法 TLS-PSK(或其他，可選)}上述模式還可以根據(jù)業(yè)務(wù)需求進(jìn)行新的認(rèn)證方法設(shè)定。
業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請(qǐng)求信息如果業(yè)務(wù)由業(yè)務(wù)簽約者發(fā)起，則所述業(yè)務(wù)簽約者向所述實(shí)體認(rèn)證中心發(fā)起認(rèn)證請(qǐng)求，如果業(yè)務(wù)由業(yè)務(wù)提供者發(fā)起，則所述業(yè)務(wù)提供者向所述實(shí)體認(rèn)證中心發(fā)起認(rèn)證請(qǐng)求；參見(jiàn)圖2，以3GPP網(wǎng)絡(luò)中的移動(dòng)用戶使用Internet中的應(yīng)用服務(wù)器(該服務(wù)器支持Kerberos認(rèn)證協(xié)議)所提供的業(yè)務(wù)為例，具體過(guò)程如下步驟201SS即用戶UE向?qū)嶓w認(rèn)證中心EAC發(fā)送業(yè)務(wù)請(qǐng)求消息，該消息中攜帶用戶UE的身份標(biāo)識(shí)、認(rèn)證能力標(biāo)識(shí)、業(yè)務(wù)類型；在請(qǐng)求消息中也可以不攜帶業(yè)務(wù)類型，而提供業(yè)務(wù)提供者SP的公開(kāi)身份標(biāo)識(shí)UID，EAC通過(guò)UID到ESD中查找相應(yīng)的業(yè)務(wù)類型。
步驟202實(shí)體認(rèn)證中心EAC根據(jù)身份標(biāo)識(shí)，并綜合業(yè)務(wù)簽約者SS以及業(yè)務(wù)提供者SP的認(rèn)證能力信息采用本地策略選取認(rèn)證模式及相應(yīng)的認(rèn)證方法，在本實(shí)施例中選取的是E2E_Kerberos模式。
實(shí)體認(rèn)證中心根據(jù)認(rèn)證模式中認(rèn)證方法的選擇策略及本地策略確定每一種認(rèn)證方法。其中本地策略可以為SS和SP的互認(rèn)證方法以及會(huì)話密鑰生成方法的選取依據(jù)雙方的認(rèn)證能力以及業(yè)務(wù)類型等；由SS和SP的互認(rèn)證方法決定是否進(jìn)行SP與EAC的互認(rèn)證，如果需要互認(rèn)證則根據(jù)SP和EAC的認(rèn)證能力以及業(yè)務(wù)類型等選取認(rèn)證方法。
步驟203根據(jù)E2E_Kerberos模式的定義，SS與EAC認(rèn)證方法為可協(xié)商，依據(jù)本地策略即雙方的認(rèn)證能力以及雙方要進(jìn)行的業(yè)務(wù)類型等，本實(shí)施例選擇了AKA認(rèn)證方法；SP與EAC認(rèn)證方法為IPSec通道或其他，并且可選，本實(shí)施例選取為空，即不進(jìn)行SP與EAC的認(rèn)證；SS與SP的認(rèn)證方法為Kerberos，可協(xié)商采用Kerberos或Kerberos改進(jìn)方案，也可以承載協(xié)議TCP或其他，本實(shí)施例依據(jù)雙方的認(rèn)證能力以及業(yè)務(wù)類型等經(jīng)過(guò)協(xié)商選取Kerberos，承載協(xié)議為T(mén)LS-Krb5；會(huì)話密鑰生成方法為T(mén)LS-Krb5或其他，可選，本實(shí)施例選取為T(mén)LS-Krb5。
根據(jù)上述選定的認(rèn)證方法，可以開(kāi)始進(jìn)行業(yè)務(wù)簽約者SS和實(shí)體認(rèn)證中心EAC的認(rèn)證。如果業(yè)務(wù)簽約者SS和實(shí)體認(rèn)證中心EAC已經(jīng)進(jìn)行過(guò)互鑒權(quán)協(xié)議AKA的互認(rèn)證并生成的共享密鑰和中間業(yè)務(wù)請(qǐng)求標(biāo)識(shí)ISR-ID在有效期內(nèi)，則不用執(zhí)行互鑒權(quán)協(xié)議AKA的互認(rèn)證步驟，直接跳到步驟209生成業(yè)務(wù)許可票據(jù)SGT；步驟204實(shí)體認(rèn)證中心EAC到實(shí)體簽約數(shù)據(jù)庫(kù)獲取用戶的認(rèn)證向量(RAND，AUTN，RES，CK，IK)。
步驟205實(shí)體認(rèn)證中心EAC在HTTP的401消息(含有g(shù)est AKAchanllenge)中發(fā)送RAND和AUTN給用戶UE，并將認(rèn)證方式標(biāo)識(shí)a放在payload信息中。
步驟206用戶UE計(jì)算并檢驗(yàn)AUTN的正確性，以確認(rèn)所述changllenge消息是否來(lái)自一個(gè)被授權(quán)的網(wǎng)絡(luò)，同時(shí)用戶UE計(jì)算CK、IK和RES。
步驟207UE發(fā)送HTTP request消息給實(shí)體認(rèn)證中心EAC，包含有Digest AKA response，由RES計(jì)算摘要值。
步驟208實(shí)體認(rèn)證中心EAC驗(yàn)證摘要值的正確性，用以認(rèn)證用戶UE的合法性。
步驟209實(shí)體認(rèn)證中心EAC生成共享密鑰Ks＝CK||IK，以及中間業(yè)務(wù)請(qǐng)求標(biāo)識(shí)ISR-ID，然后實(shí)體認(rèn)證中心EAC利用共享密鑰Ks以及業(yè)務(wù)簽約者SS的身份標(biāo)識(shí)，業(yè)務(wù)提供者SP的公開(kāi)身份標(biāo)識(shí)UID生成衍生密鑰Ksp，并將其放在業(yè)務(wù)許可票據(jù)SGT中，票據(jù)的內(nèi)容為衍生密鑰Ksp、業(yè)務(wù)簽約者SS的中間業(yè)務(wù)請(qǐng)求標(biāo)識(shí)ISR-ID、業(yè)務(wù)簽約者SS的公開(kāi)身份標(biāo)識(shí)UID、有效期、防重放攻擊參數(shù)，并由實(shí)體認(rèn)證中心EAC與業(yè)務(wù)提供者SP的共享密鑰加密。
步驟210實(shí)體認(rèn)證中心EAC發(fā)送200OK消息傳送給UE，表示認(rèn)證成功結(jié)束；所述200OK消息中包含共享密鑰的有效期、中間業(yè)務(wù)請(qǐng)求標(biāo)識(shí)ISR-ID，以及由共享密鑰Ks加密的業(yè)務(wù)許可票據(jù)SGT。
步驟211用戶UE也生成所述的共享密鑰Ks＝CK||IK以及衍生密鑰Ksp，然后解密獲得中間業(yè)務(wù)請(qǐng)求標(biāo)識(shí)ISR-ID、有效期以及業(yè)務(wù)許可票據(jù)SGT連同認(rèn)證模式信息關(guān)聯(lián)保存在本地。
參見(jiàn)圖3，業(yè)務(wù)簽約者(SS)與業(yè)務(wù)提供者間進(jìn)行互認(rèn)證，具體過(guò)程如下步驟212業(yè)務(wù)簽約者SS向業(yè)務(wù)提供者SP發(fā)送ClientHello消息，該消息中攜帶業(yè)務(wù)提供者SP的公開(kāi)身份標(biāo)識(shí)UID、業(yè)務(wù)簽約者SS所支持的TLS-KRB5加密套件，以及認(rèn)證模式E2E_Kerberos的相應(yīng)信。
所述認(rèn)證模式E2E_Kerberos的相應(yīng)信息指該模式定義中的業(yè)務(wù)簽約者SS與業(yè)務(wù)提供者SP的認(rèn)證方法和會(huì)話密鑰生成方法。
步驟213業(yè)務(wù)提供者SP收到Client Hello消息后，發(fā)現(xiàn)SessionID字段為空，選擇雙方都支持的TLS-KRB5加密套件，發(fā)送ServerRequest消息ServerHello，然后發(fā)送ServerHelloDone消息。
步驟214收到ServiceHelloDone消息后，業(yè)務(wù)簽約者SS向業(yè)務(wù)提供者SP發(fā)送ClientKeyExchange消息，通過(guò)這條消息雙方獲得預(yù)共享秘密參數(shù)PreMasterSecret；業(yè)務(wù)簽約者SS利用PreMasterSecret以及隨機(jī)數(shù)生成會(huì)話密鑰MasterSecret；然后，業(yè)務(wù)簽約者SS在ChangeCipherSpec消息后立即發(fā)送Finished消息，用于正式密鑰交換和驗(yàn)證。
步驟215業(yè)務(wù)提供者SP解密業(yè)務(wù)許可票據(jù)SGT檢驗(yàn)票據(jù)的有效性，獲得共享衍生密鑰Ksp，并利用共享衍生密鑰Ksp解密PreMasterSecret，然后由PreMasterSecret以及隨機(jī)數(shù)等生成業(yè)務(wù)簽約者SS和業(yè)務(wù)提供者SP會(huì)話密鑰MasterSecret；然后業(yè)務(wù)提供者SP驗(yàn)證業(yè)務(wù)簽約者SS的Finished消息中的信息是否正確，如果不正確，停止當(dāng)前步驟。
步驟216如果所述Finished消息中的信息正確，發(fā)送ChangeCipherSpec消息，并把Finished消息返回給業(yè)務(wù)簽約者SS。
步驟217業(yè)務(wù)簽約者SS驗(yàn)證Finished消息中的信息正確性，如果業(yè)務(wù)簽約者SS驗(yàn)證Finished消息正確，那么雙方認(rèn)證和密鑰交換步驟成功結(jié)束。
步驟218業(yè)務(wù)簽約者SS和業(yè)務(wù)提供者SP開(kāi)始傳輸業(yè)務(wù)通信數(shù)據(jù)。
當(dāng)上述步驟所建立的會(huì)話沒(méi)有過(guò)期時(shí)，業(yè)務(wù)簽約者SS再次向業(yè)務(wù)提供者SP發(fā)送業(yè)務(wù)請(qǐng)求，則可以重用上次會(huì)話生成的PreMasterSecret，生成本次業(yè)務(wù)通信的新的會(huì)話密鑰MasterSecret，參見(jiàn)圖4，所述步驟如下步驟219業(yè)務(wù)簽約者SS向業(yè)務(wù)提供者SP發(fā)送Client Hello消息，并攜帶上次會(huì)話的Session ID。
步驟220業(yè)務(wù)提供者SP收到Client Hello消息后，發(fā)現(xiàn)SessionID不為空，且能夠匹配到相關(guān)聯(lián)的安全連接信息，重用該Session ID標(biāo)識(shí)會(huì)話，向業(yè)務(wù)簽約者SS發(fā)送ServerHello，并攜帶該Session ID，以及發(fā)送ServerHelloDone。
步驟221業(yè)務(wù)簽約者SS利用與業(yè)務(wù)提供者SP共享的PreMasterSecret生成會(huì)話密鑰MasterSecret。
步驟222業(yè)務(wù)簽約者SS向業(yè)務(wù)提供者SP發(fā)送ChangeCipherSpec消息，以及Finished消息。
步驟223業(yè)務(wù)提供者SP檢驗(yàn)Finished消息無(wú)誤后，利用同樣的PreMasterSecret生成會(huì)話密鑰MasterSecret。
步驟224業(yè)務(wù)提供者SP發(fā)送ChangeCipherSpec消息，并返回Finished消息。
步驟225如果Finished消息無(wú)誤，雙方互認(rèn)證結(jié)束，開(kāi)始傳輸通信數(shù)據(jù)。
參見(jiàn)圖5，本發(fā)明還提供了一種端到端通信認(rèn)證裝置，所述裝置包括發(fā)送模塊，用于業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請(qǐng)求；選擇模塊，用于所述實(shí)體認(rèn)證中心收到所述認(rèn)證請(qǐng)求后，選擇認(rèn)證模式并發(fā)送給業(yè)務(wù)實(shí)體；
認(rèn)證模塊，用于業(yè)務(wù)實(shí)體根據(jù)所述選擇的認(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.一種端到端通信認(rèn)證方法，其特征在于，根據(jù)具體業(yè)務(wù)定義認(rèn)證模式，所述方法包括以下步驟步驟A業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請(qǐng)求信息，所述請(qǐng)求信息包括業(yè)務(wù)實(shí)體的身份標(biāo)識(shí)、認(rèn)證能力標(biāo)識(shí)和業(yè)務(wù)類型；步驟B所述實(shí)體認(rèn)證中心收到所述認(rèn)證請(qǐng)求后，選擇認(rèn)證模式并發(fā)送給業(yè)務(wù)實(shí)體；步驟C業(yè)務(wù)實(shí)體根據(jù)所述選擇的認(rèn)證模式進(jìn)行認(rèn)證。
2.如權(quán)利要求1所述的端到端通信認(rèn)證方法，其特征在于，所述認(rèn)證模式至少設(shè)定以下認(rèn)證方法中的一種業(yè)務(wù)簽約者和認(rèn)證中心的認(rèn)證方法、業(yè)務(wù)提供者和認(rèn)證中心的認(rèn)證方法、業(yè)務(wù)簽約者和業(yè)務(wù)提供者的認(rèn)證方法以及會(huì)話密鑰的生成方法。
3.如權(quán)利要求2所述的端到端通信認(rèn)證方法，其特征在于，所述認(rèn)證模式中設(shè)定了所述認(rèn)證方法的選擇策略。
4.如權(quán)利要求3所述的端到端通信認(rèn)證方法，其特征在于，所述選擇策略具體包括所述認(rèn)證方法是否必選。
5.如權(quán)利要求3所述的端到端通信認(rèn)證方法，其特征在于，所述選擇策略具體包括所述認(rèn)證方法是否可協(xié)商。
6.如權(quán)利要求1所述的端到端通信認(rèn)證方法，其特征在于，所述步驟B具體包括步驟B1所述實(shí)體認(rèn)證中心接收所述業(yè)務(wù)實(shí)體發(fā)送的認(rèn)證請(qǐng)求信息；步驟B2所述實(shí)體認(rèn)證中心查詢實(shí)體簽約數(shù)據(jù)庫(kù)，得到雙方的認(rèn)證能力信息；步驟B3所述實(shí)體認(rèn)證中心根據(jù)得到的認(rèn)證能力信息及業(yè)務(wù)類型采用本地策略選擇認(rèn)證模式；步驟B4所述實(shí)體認(rèn)證中心發(fā)送所述選擇的認(rèn)證模式。
7.如權(quán)利要求6所述的端到端通信認(rèn)證方法，其特征在于，所述步驟B3具體包括所述實(shí)體認(rèn)證中心根據(jù)認(rèn)證模式中認(rèn)證方法的選擇策略及本地策略確定認(rèn)證方法。
8.如權(quán)利要求1所述的端到端通信認(rèn)證方法，其特征在于，所述步驟C具體包括業(yè)務(wù)實(shí)體收到所述選擇的認(rèn)證模式后，根據(jù)所述認(rèn)證模式中的認(rèn)證方法進(jìn)行相應(yīng)的認(rèn)證過(guò)程。
9.如權(quán)利要求1所述的端到端通信認(rèn)證方法，其特征在于，所述步驟C后還包括業(yè)務(wù)實(shí)體間進(jìn)行業(yè)務(wù)通信；如果所述的業(yè)務(wù)實(shí)體間的業(yè)務(wù)通信不止一次，并且認(rèn)證結(jié)果沒(méi)有過(guò)期，則可以重用上次認(rèn)證生成的共享密鑰材料，生成本次業(yè)務(wù)通信的新的會(huì)話密鑰；如果所述認(rèn)證結(jié)果過(guò)期，則重新進(jìn)行認(rèn)證。
10.如權(quán)利要求1所述的端到端通信認(rèn)證方法，其特征在于，所述步驟A之前還包括如果業(yè)務(wù)由業(yè)務(wù)簽約者發(fā)起，則所述業(yè)務(wù)簽約者向所述實(shí)體認(rèn)證中心發(fā)起認(rèn)證請(qǐng)求；如果業(yè)務(wù)由業(yè)務(wù)提供者發(fā)起，則所述業(yè)務(wù)提供者向所述實(shí)體認(rèn)證中心發(fā)起認(rèn)證請(qǐng)求。
11.一種端到端通信認(rèn)證裝置，其特征在于，所述裝置包括發(fā)送模塊，用于業(yè)務(wù)實(shí)體向?qū)嶓w認(rèn)證中心發(fā)送認(rèn)證請(qǐng)求信息；選擇模塊，用于所述實(shí)體認(rèn)證中心收到所述認(rèn)證請(qǐng)求信息后，選擇認(rèn)證模式并發(fā)送給業(yè)務(wù)實(shí)體；認(rèn)證模塊，用于業(yè)務(wù)實(shí)體根據(jù)所述選擇的認(rèn)證模式進(jìn)行認(rèn)證。
全文摘要
本發(fā)明提供了一種端到端通信認(rèn)證的方法及裝置。屬于網(wǎng)絡(luò)安全領(lǐng)域。為了解決現(xiàn)有技術(shù)中過(guò)程劃分過(guò)于僵化、認(rèn)證過(guò)程中的交互信息有重復(fù)、不合理、認(rèn)證過(guò)程不靈活、不能很好地兼容現(xiàn)有各種機(jī)制的缺點(diǎn)，本發(fā)明提供了一種端到端通信認(rèn)證的方法，所述方法包括發(fā)送認(rèn)證請(qǐng)求、選擇認(rèn)證模式并發(fā)送、進(jìn)行認(rèn)證的步驟。本發(fā)明還提供了一種端到端通信認(rèn)證裝置，該裝置包括發(fā)送模塊、選擇模塊、認(rèn)證模塊。采用本發(fā)明所述技術(shù)方案使認(rèn)證過(guò)程得到了全局優(yōu)化，能夠以統(tǒng)一的方式處理各種認(rèn)證方法。
文檔編號(hào)H04L9/32GK101060406SQ20061007925
公開(kāi)日2007年10月24日 申請(qǐng)日期2006年4月20日 優(yōu)先權(quán)日2006年4月20日
發(fā)明者范絮妍, 位繼偉 申請(qǐng)人:華為技術(shù)有限公司