專利名稱：會議系統(tǒng)中的安全密鑰管理的制作方法
技術(shù)領(lǐng)域：
本發(fā)明總體上涉及通信安全性，并且更具體地，涉及用于在諸如呼叫會議系統(tǒng)和多媒體通信系統(tǒng)的媒體平面這樣的通信環(huán)境中使用的安全密鑰管理協(xié)議。
背景技術(shù)：
在多媒體通信系統(tǒng)中提供的現(xiàn)有多媒體應用并不支持媒體平面中的安全性。關(guān)于媒體平面安全性的問題是相對新的問題。在諸如因特網(wǎng)協(xié)議(IP)多媒體子系統(tǒng)(IMQ這樣的多媒體通信系統(tǒng)中的現(xiàn)有提議是以某種基于令牌的對稱密鑰方法為基礎(chǔ)，該令牌是使用密鑰管理服務器(其潛在地創(chuàng)建和分發(fā)密鑰)來管理的。3GPP (第三代合作伙伴項目)技術(shù)報告(TR) 33.擬8討論了用于 IMS媒體平面加密的現(xiàn)有提議，通過引用的方式將其公開內(nèi)容合并于此。然而，這些現(xiàn)有解決方案是不可擴展的(因為服務器應當高度可用并且總是在線)，其并不提供實體的認證， 并且此外，其在服務器處托管(escrow)密鑰。相反地，諸如SKYPE (盧森堡的Skype Technologies S. Α.的商品名稱)這樣的非 IMS應用以及其它客戶端到客戶端的多媒體應用在認證和無密鑰托管的情況下提供了端到端的隱私性。然而，該解決方案依賴于使用要求高度可用的公共密鑰基礎(chǔ)設(shè)施(PKI)的證書，其中管理所述PKI是極其昂貴的。此外，該解決方案沒有很好地擴展用于群組會議應用，它也沒有提供在缺少PKI情況下對通信的合法攔截。此外，類似的密鑰管理安全性問題存在于會議系統(tǒng)中，其中各方通過會議服務器來參與呼叫會話。因而，需要一種用于在諸如呼叫會議系統(tǒng)和多媒體通信系統(tǒng)的媒體平面這樣的通信環(huán)境中使用的安全密鑰管理解決方案。

發(fā)明內(nèi)容
本發(fā)明的原理提供了用于在諸如會議系統(tǒng)這樣的通信環(huán)境中使用的一個或多個安全密鑰管理協(xié)議。例如，在一個方面中，一種用于在通信系統(tǒng)中管理兩方或更多方之間的會議的方法包括以下步驟。在通信系統(tǒng)的會議管理元件與設(shè)法參與會議的所述兩方或更多方中的每一方之間實施基于身份的認證密鑰交換操作，其中，在所述會議管理元件與所述兩方或更多方之間交換的消息是基于所述消息的接收者的相應身份來進行加密的，并且進一步地， 其中所述會議管理元件在密鑰認證操作期間從每一方接收基于由該方選擇的隨機數(shù)所計算的隨機密鑰分量。所述會議管理元件向每一方發(fā)送包括由各方計算的隨機密鑰分量的集合。所述會議管理元件從每一方接收隨機群組密鑰分量，其中，由每一方經(jīng)由基于以下內(nèi)容的計算方法來計算所述隨機群組密鑰分量在密鑰認證操作期間由該方所使用的隨機數(shù)，以及由設(shè)法參與所述會議的所述兩方或更多方中的其它方的子集所計算的隨機密鑰分量。所述會議管理元件向每一方發(fā)送包括由各方計算的隨機群組密鑰分量的集合，從而使得每一方可以計算相同的群組密鑰以便在通過所述會議管理元件與每一個其它方進行通信時使用。在一個實施例中，所述會議管理元件不是所述會議中的參與方，并且由此不能計算群組密鑰。在另一個實施例中，所述會議管理元件是會議呼叫中的參與方，并且由此能夠計算群組密鑰。在一個實施例中，由每一方計算的群組密鑰被表示為=Nai (Zi-I) +(N-I)
Xi+1+. . . +Xi_2，其中N表示設(shè)法參與會議的各方的總數(shù)，ai表示由給定方選擇的隨機數(shù),Zi表示由給定方計算的隨機密鑰分量，&表示由給定方計算的隨機群組密鑰分量，并且i表示在 N方會議中用于給定方的會議排序的編號，其中當i = 1時，i-1 = N，而當i = N時，i+1 =
Io在一個實施例中，用于給定方的隨機密鑰分量通過如下表示的計算方法來計算 BiP,其中％是由給定方選擇的隨機數(shù)，并且P是選自與基于身份加密的密鑰認證操作相關(guān)聯(lián)的群組的點(point)。在一個實施例中，用于給定方的隨機群組密鑰分量通過如下表示的計算方法來計算a, (BitlP-Bi^1P)，其中 是由給定方選擇的隨機數(shù)，ai+1P是由在會議排序中就在給定方之后的一方發(fā)送到會議管理元件的隨機密鑰分量，Bi^1P是由在會議排序中就在給定方之前的一方發(fā)送到會議管理元件的隨機密鑰分量，并且P是選自與密碼密鑰交換協(xié)議相關(guān)聯(lián)的群組的點。應當理解，雖然本發(fā)明的原理特別適合因特網(wǎng)協(xié)議(IP)多媒體子系統(tǒng)(IMS)環(huán)境，但是本發(fā)明并不意在限制于此。也就是說，本發(fā)明的原理通?？蓱糜谄渲衅谕峁┌踩荑€管理特征的任何合適的通信系統(tǒng)。根據(jù)結(jié)合附圖閱讀的對本發(fā)明的說明性實施例的以下詳細描述，本發(fā)明的這些和其它目的、特征和優(yōu)點將變得顯而易見。


圖IA圖示了根據(jù)本發(fā)明實施例的私有密鑰獲取方法；圖IB圖示了根據(jù)本發(fā)明實施例的基于身份的認證密鑰交換方法；圖2圖示了根據(jù)本發(fā)明實施例的密鑰分路(key forking)方法；圖3圖示了根據(jù)本發(fā)明實施例的呼叫重定向方法；圖4A圖示了根據(jù)本發(fā)明實施例的遲延遞送(deferred delivery)方法；圖4B圖示了根據(jù)本發(fā)明另一實施例的遲延遞送方法；圖5圖示了根據(jù)本發(fā)明實施例的合法攔截方法；圖6A圖示了根據(jù)本發(fā)明實施例的會議管理方法；
圖6B圖示了根據(jù)本發(fā)明實施例的在會議管理方法中對參與者的添加；圖6C圖示了根據(jù)本發(fā)明實施例的在會議管理方法中對參與者的刪除；圖7圖示了根據(jù)基于IMS的本發(fā)明實施例的用于安全密鑰管理協(xié)議的網(wǎng)絡(luò)架構(gòu)；圖8圖示了根據(jù)基于IMS的本發(fā)明實施例的密鑰分路方法；圖9圖示了根據(jù)基于IMS的本發(fā)明實施例的重定向方法；圖10圖示了根據(jù)基于IMS的本發(fā)明實施例的具有三個參與者的會議方法；以及圖11圖示了適合實現(xiàn)根據(jù)本發(fā)明實施例的一個或多個協(xié)議的通信(計算)設(shè)備和數(shù)據(jù)網(wǎng)絡(luò)的廣義硬件架構(gòu)。
具體實施例方式如在此所使用的，短語“多媒體通信系統(tǒng)”通常被定義為能夠傳輸兩個或更多類型的媒體(包括但不限于基于文本的數(shù)據(jù)、基于圖形的數(shù)據(jù)、基于語音的數(shù)據(jù)和基于視頻的數(shù)據(jù))的任何通信系統(tǒng)。如在此所使用的，短語“媒體平面”通常被定義為多媒體通信系統(tǒng)的以下功能部分依照該功能部分，在呼叫會話中在兩方或更多方之間交換一個或多個類型的媒體。這與 “控制平面”不同，“控制平面”是多媒體通信系統(tǒng)的以下功能部分依照該功能部分，執(zhí)行呼叫協(xié)商/調(diào)度以便建立呼叫會話?？梢耘c之一起使用本發(fā)明技術(shù)的媒體平面應用的例子包括但不限于基于IP的語音(VoIP)、即時消息收發(fā)(IM)、視頻/音頻IM，以及視頻共享。應當明白，媒體平面含有應用層業(yè)務。如在此所使用的，術(shù)語“密鑰”通常被定義為密碼協(xié)議的輸入，用于諸如但不限于實體認證、隱私性、消息完整性等等的目的。為了便于參考，詳細的描述被劃分如下。章節(jié)I描述了基于身份的加密和基于身份的認證密鑰交換操作的一般原理。章節(jié)II描述了在一般通信環(huán)境上下文中根據(jù)本發(fā)明的說明性原理的安全密鑰管理解決方案。章節(jié)III描述了在因特網(wǎng)協(xié)議(IP)多媒體子系統(tǒng)(IMS)環(huán)境上下文中根據(jù)本發(fā)明的說明性原理的安全密鑰管理解決方案。章節(jié)IV描述了根據(jù)本發(fā)明的用于實現(xiàn)一個或多個安全密鑰管理協(xié)議的說明性計算系統(tǒng)。I.基于身份的加密(IBE)和基于身份的認證密鑰交換(IBAKE)在解釋本發(fā)明的安全密鑰管理技術(shù)的說明性實施例之前，提供了 IBE和IBAKE的一般原理。A.基于身份的加密基于身份的加密(IBE)協(xié)議由Boneh和Franklin提供，參見Dan Boneh,Matthew K. Franklin 的 “Identity-Based Encryption from the Weil Pairing，，Advances in Cryptology-Proceedings of CRYPTO 2001 (2001)，通過引用的方式將其公開內(nèi)容合并于此。這種不對稱密碼加密協(xié)議允許參與者將‘身份’(示例電子郵件id或域名)用作公共密鑰，并且不需要常常與公共密鑰加密方法(諸如RSA(Rivest、Siamir和Adleman))相關(guān)聯(lián)的大規(guī)模公共密鑰基礎(chǔ)設(shè)施。Boneh和Franklin的針對該問題的方法在有限域上使用基于橢圓曲線的雙線性映射，并且依賴于雙線性判定Diffie-Hellman問題。IBE涉及下面的數(shù)學工具和參數(shù)假設(shè)E是在有限域F上的橢圓曲線，并且假設(shè)P是大素數(shù)階的點。
假設(shè)e =ExE- — G是在E上的雙線性映射。典型的例子是W^eil配對，并且因此G 將是第η個單位根(n-th roots of unity)的群組，其中η是在F上的E上的點數(shù)的函數(shù)。假設(shè)s是非零正整數(shù)并且是在密鑰生成函數(shù)(KGF)中存儲的秘密。這是系統(tǒng)范圍的秘密并且不表露在KGF之外。假設(shè)Ppub = sP是所有參與者已知的系統(tǒng)的公共密鑰。記住sP表示E中的點，因為E是一個群組。假設(shè)H1是已知的散列函數(shù)，該散列函數(shù)獲取串并且將其分派給橢圓曲線上的點， 艮口，在E上H1 (A) = A，其中A通常是身份，并且也是A的公共密鑰。假設(shè)dA = sA是由KGF計算的并且僅遞送給A的私有密鑰。假設(shè)H2是已知的散列函數(shù)，該散列函數(shù)獲取G的元素并且將其分派給串。假設(shè)m是必須被加密和發(fā)送給A的消息。由Boneh和Franklin描述的加密函數(shù)如下假設(shè)仏=e (Qa, Ppub)，并且假設(shè)r是隨機數(shù)。EncryptionA(m) = (rP，m xor H2 (gAr))；換句話說，m的加密輸出具有兩個坐標u 和V，其中U = rp且V = m xor H2 (gAr)。注意到“xor”指的是異或邏輯函數(shù)。為了解密(u，ν)，A使用下面的公式來恢復m m = ν xor H2 (e (dA, u))。對該公式的證明是雙線性映射中的簡明練習(straight forward exercise)，并且實際上A具有秘密dA (僅是A知道私有密鑰，而其它參與者并不知道私有密鑰)。而且觀察到，首先計算dA的KGF也可以解密該消息，從而導致KGF是事實上的密鑰托管服務器。B.基于身份的認證密鑰交換在2009年2月17日提交的通過序列號No. 12/372，242標識的美國專利申請中描述了基于身份的認證密鑰交換(IBAKE)，通過引用的方式將其公開內(nèi)容合并于此。IBAKE協(xié)議允許設(shè)備彼此相互認證，并且導出提供了完美前向和后向保密的密鑰。在這里描述的IBAKE實施例中，該協(xié)議的基本設(shè)置涉及以上在子章節(jié)A中討論的數(shù)學構(gòu)造和參數(shù)。記住該協(xié)議是不對稱的，但并不要求任何PKI支持；相反，該協(xié)議采用了充當密鑰生成函數(shù)的離線服務器。下面概述了該協(xié)議的細節(jié)假設(shè)A、B是正在嘗試認證和商定密鑰的兩個實體(或者兩方，其中A表示第一方的計算機系統(tǒng)，并且B表示第二方的計算機系統(tǒng))。將使用A和B來表示它們對應的身份，其按照定義也表示它們的公共密鑰。假設(shè)H1OV) = A和氏⑶=%是與公共密鑰相對應的在橢圓曲線上的相應點。實際上，也可將A和( 稱為公共密鑰，因為在身份與通過應用H1所獲得的曲線上的點之間存
在一對一的對應性。假設(shè)χ是由A選擇的隨機數(shù)，并且假設(shè)y是由B選擇的隨機數(shù)。在A和B之間的協(xié)議交換包括以下步驟在第一步驟中，A計算xP(即，在E上使用加法定律，P與其自身相加χ次作為E上的點)，使用B的公共密鑰來對其進行加密，并且將其傳送到B。在該步驟中，加密指的是以上在子章節(jié)A中描述的基于身份的加密。在接收到已加密的消息時，B解密該消息并獲得xP。隨后B計算yP，并且使用A的公共密鑰來加密該對IxP，yP}，并且然后在第二步驟中將其傳送給A。在接收到該消息時，A解密該消息并獲得yP。隨后，A使用B的公共密鑰來加密yP 并在第三步驟中將其發(fā)回給B。在此之后，A和B都將xyP計算為會話密鑰。觀察到A隨機地選擇χ并且在協(xié)議交換的第二步驟中接收到y(tǒng)P。這允許A通過使yP與其自身相加χ次來計算xyP。相反地，B隨機地選擇y并且在協(xié)議交換的第一步驟中接收到xP。這允許B通過使χΡ與其自身相加y次來計算xyP。注意到該協(xié)議的任何應用均可以利用具有身份的頭部數(shù)據(jù)來確保協(xié)議正確地起作用。這是相對標準的并且?guī)缀踹m用于針對密鑰協(xié)定的任何協(xié)議交換。還注意到，χ是隨機的但xP卻不提供關(guān)于χ的任何信息。因此，xP是基于由A選擇的隨機秘密的密鑰的分量。類似地，y是隨機的但yP卻不提供關(guān)于y的任何信息。因此， yP是基于僅B已知的隨機秘密的密鑰的分量。進一步注意到，xyP可以充當會話密鑰。而且，該會話密鑰可以是xyP的任何已知函數(shù)。也就是說，該會話密鑰可以等于f(xyP)，其中f對于兩方來說都是已知的并且不要求其是秘密(即，公諸于世)。對f的一個實踐要求應當是在沒有χ或y的知識的情況下是難以計算f的，并且從密碼的角度來看，輸出具有滿意的長度，例如大約1 個比特或更多比特。 IBAKE協(xié)議的一些屬性包括-免于密鑰托管觀察到在協(xié)議交換中的所有步驟都使用IBE來進行加密。因此顯然KGF可以解密所有的交換。然而，KGF無法計算會話密鑰。這是因為橢圓曲線 Diffie-Hellman問題的困難性。換句話說，給定xP和yP，在計算上難以計算xyP。-相互認證密鑰協(xié)定觀察到在協(xié)議交換中的所有步驟都使用IBE來進行加密。 特別地，在第一和第三步驟中僅B可以解密由A發(fā)送的消息的內(nèi)容，并且類似地，在第二步驟中僅A可以解密由B發(fā)送的消息的內(nèi)容。此外，在第二步驟結(jié)束時，A可以驗證B的真實性，因為僅在由B在第一步驟中解密了內(nèi)容之后才可在第二步驟中發(fā)送xP。類似地，在第三步驟結(jié)束時，B可以驗證A的真實性，因為僅在正確地解密了第二步驟的內(nèi)容(而這僅通過A才是可能的)之后才可在第三步驟中發(fā)回yP。最后，A和B都可以商定相同的會話密鑰。換句話說，該協(xié)議是基于IBE的相互認證密鑰協(xié)定協(xié)議。在以上描述提供了用于協(xié)議的安全性的動機時，可以容易地提供安全性的密碼證明。該協(xié)議的困難性依賴于橢圓曲線 Diffie-He 1 Iman問題的困難性，其受到橢圓曲線的選擇的影響。-完美前向和后向保密由于X和y是隨機的，因此XyP總是新鮮的并且與A和B 之間的任何過去或未來的會話不相關(guān)。-無口令I(lǐng)BAKE協(xié)議并不要求在A和B之間的口令或秘密密鑰的任何離線交換。 實際上，該方法顯然適用于通過任何通信網(wǎng)絡(luò)第一次通信的任何兩方。唯一的要求是確保 A和B都知道彼此的公共密鑰，例如，通過目錄服務。II.安全密鑰管理和說明性擴展已經(jīng)意識到，因特網(wǎng)已從盡力而為數(shù)據(jù)網(wǎng)絡(luò)快速演進到支持包括多媒體在內(nèi)的各類業(yè)務的多服務IP(因特網(wǎng)協(xié)議)網(wǎng)絡(luò)。這伴隨著移動無線網(wǎng)絡(luò)的快速成長，并且已經(jīng)產(chǎn)生了技術(shù)挑戰(zhàn)。從技術(shù)視角來看，已經(jīng)很好地合理解決的中心挑戰(zhàn)是呼叫控制功能(包括發(fā)信號通知建立呼叫)與應用層業(yè)務(常被稱為“媒體平面”)的分離。諸如H323(參見例如國際電信聯(lián)盟標準化組(ITU-T)建議H. 323，通過引用的方式將其公開內(nèi)容合并于此)、 會話發(fā)起協(xié)議或SIP(參見例如因特網(wǎng)工程任務組IETF RFC 3沈1，通過引用的方式將其公開內(nèi)容合并于此)和IMS(參見例如3GPP技術(shù)規(guī)范TS 23. 218、TS 23. 228、TS 24. 228、TS 對.2四和TS 24. 930，通過引用的方式將其公開內(nèi)容合并于此)的呼叫控制協(xié)議已經(jīng)由諸如IETF和3GPP的各種組織進行了標準化，并且處于在固定和移動網(wǎng)絡(luò)上采用的各個階段。同時，已經(jīng)合并了用于確保各種級別的信令安全性的詳細機制。然而，在媒體平面中，雖然諸如傳輸層安全性或TLS(參見例如IETF RFC 2M6，通過引用的方式將其公開內(nèi)容合并于此)、安全實時傳輸協(xié)議或SRTP(參見例如IETF RFC 3711，通過引用的方式將其公開內(nèi)容合并于此)和安全多用途因特網(wǎng)郵件擴展或SMIME(參見例如IETF RFC 2633，通過引用的方式將其公開內(nèi)容合并于此)的協(xié)議提供了用于各種應用的容器格式，但是媒體平面中的安全性解決方案缺少用于支持應用層中的端到端安全密鑰管理的一致性和標準化的方法。本發(fā)明的原理主要解決該問題。特別地，本發(fā)明的原理為媒體平面提供了一種可擴展的應用和協(xié)議不可知安全密鑰管理框架。在說明性框架中，本發(fā)明的解決方案利用以上在章節(jié)I. B中描述的不對稱(因此是公共密鑰)基于身份的認證密鑰交換(IBAKE)協(xié)議。說明性實施例描述了密鑰交換機制以支持各種特征，舉例來說，諸如安全的兩方媒體平面通信、安全多方會議、安全呼叫分路、安全呼叫重定向，以及安全遲延遞送應用。除了提供用于安全密鑰管理的可擴展框架之外，該設(shè)計和框架的一些示例性方面還包括-使用離線密鑰管理服務器(KMS)，其顯著降低了所需網(wǎng)絡(luò)支持的復雜性。記住在公共密鑰設(shè)置要求中不對稱協(xié)議總是精心設(shè)計了支持證書管理(包括撤回)的公共密鑰基礎(chǔ)設(shè)施(PKI)。基于對稱密鑰的密鑰管理服務器按照定義是“永遠在線(always on) ”服務器，具有恒定的同步和更新。通過消除“永遠在線”要求，本發(fā)明的框架顯著降低了成本并支持可擴展性。-消除在基于身份的協(xié)議中固有的任何被動密鑰托管。記住具有密鑰管理服務器的對稱密鑰協(xié)議無法消除該問題。而且，回想到(以上在章節(jié)I. A.中描述的)現(xiàn)有基于身份的加密協(xié)議存在密鑰托管問題；使用(以上在章節(jié)I. B.中描述的)IBAKE來解決問題。-協(xié)議框架固有地支持在密鑰交換中涉及的伴隨有完美保密的實體的相互認證。-本發(fā)明的說明性實施例重用了現(xiàn)有網(wǎng)絡(luò)元件架構(gòu)，并且盡可能多地重用現(xiàn)有協(xié)議容器格式。例如，在會議應用中，說明性實施例重用了會議服務器來啟用會議，但確保會議服務器不知道用于通信的群組密鑰(除非其也是該會議的一方，如下面將解釋的)。-盡管本發(fā)明的原理消除了被動密鑰托管，但是當存在對攔截呼叫的執(zhí)法的合法要求時，本發(fā)明的協(xié)議也提供對于發(fā)現(xiàn)密鑰的無縫支持。在根據(jù)基于身份的不對稱密碼框架的說明性實施例中，每個參與者均具有公共密鑰和私有密鑰。公共密鑰是基于身份的。私有密鑰對應于公共密鑰并且由密鑰管理服務器或服務(KMS)來發(fā)布。參與者可以離線地從KMS獲得私有密鑰。僅舉例來說，參與者一個月與他們的KMS聯(lián)系一次(更一般地，針對預訂的長度)來獲得私有密鑰。私有密鑰也可以根據(jù)使用的頻率來獲得。假定安全性關(guān)聯(lián)存在于KMS和參與者之間。在密鑰交換期間對消息的加密和解密是基于IBE。注意到，假定KMS的公共參數(shù)是公共可用的(例如，在線于Web站點上)。通常，根據(jù)本發(fā)明的說明性實施例的安全密鑰管理方法包括兩個主要階段。在第一階段中，參與者(各方)從諸如KMS這樣的密鑰服務獲得私有密鑰。在第二階段中，在設(shè)法在基于多媒體的呼叫會話中進行通信的兩方或更多方之間實施基于身份的認證密鑰交換。在所述兩方或更多方之間交換的消息是基于消息的接收者的相應身份來加密的。而且， 在各方之間交換的已加密的消息含有與各方相關(guān)聯(lián)的身份。圖IA示出了安全密鑰管理方法的第一階段，S卩，私有密鑰獲取。如圖所示，兩方的通信設(shè)備(更一般地，計算設(shè)備)102分別從相應的KMS104請求和獲得私有(或秘密) 密鑰。根據(jù)安全通信協(xié)議來實現(xiàn)私有密鑰交換106。安全通信協(xié)議的例子包括但不限于 因特網(wǎng)協(xié)議安全性或IPkc (參見例如IETF RFC 2406、IETF RFC 2409、IETF RFC 4306和 IETFRFC 4308，通過引用的方式將其公開內(nèi)容合并于此)以及傳輸層安全性或TLS (參見例如IETF RFC 2M6，通過引用的方式將其公開內(nèi)容合并于此)。廣義的自舉架構(gòu)或GBA(參見例如3GPP技術(shù)規(guī)范(TS)33. 220，通過引用的方式將其公開內(nèi)容合并于此)可用于確定要在每一方和KMS之間的安全通信協(xié)議中使用的密鑰。在一個例子中，可以具有在連接到 KMS服務器并在應用層中使用TLS的客戶端設(shè)備中運行的應用(以上的傳輸控制協(xié)議或 TCP,參見例如 W. Richard Stevens. TCP/IP Illustrated, Volume 1 :The Protocols, ISBN 0-201-63346-9 ；W.Richard Stevens and Gary R. Wright. TCP/IP Illustrated, Volume 2 :The Implementation, ISBN0-201-63354-X ；W. Richard Stevens. TCP/IP Illustrated, Volume 3 :TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols, ISBN0-201-63495-3，通過引用的方式將其公開內(nèi)容合并于此)，其在網(wǎng)絡(luò)層使用GBA密鑰或IPkc，并且GBA密鑰作為預先共享的密鑰。注意到，左邊的設(shè)備被認為是發(fā)起者(I)而右邊的設(shè)備是響應者(R)。該指定是源自以下事實在左邊的設(shè)備設(shè)法發(fā)起與右邊的設(shè)備的多媒體呼叫會話。如圖所示，每個設(shè)備向KMS提供標識符及其請求，KMS用私有(秘密)密鑰對此做出響應。在發(fā)起者設(shè)備102-1的情況下，一個標識符被提供給KMS 104-1，并且一個私有密鑰I-SK被提供給該設(shè)備作為響應。在響應者設(shè)備102-R的情況下，兩個分離的標識符被發(fā)送給KMS 104-R，即，R和R1。作為響應，KMS向響應者提供兩個私有密鑰R_SK和R1_SK。當然，每一方可以基于某種私有密鑰獲取調(diào)度來請求和獲得更多或更少的私有密鑰。這可以是基于時間的調(diào)度(例如，一個月的時段)、基于呼叫會話頻率的調(diào)度(例如，當需要進行呼叫時)和基于預訂的調(diào)度(例如，該方預訂了 KMS的密鑰服務達到某個時間長度，或者基于預訂結(jié)束條件的發(fā)生)。而且，應當理解，給定方可以具有多個公共身份。例如，B方(“Bob”)可以具有兩個身份bob@work. com和bob@home. com。對于這兩個身份，可以存在兩個不同的公共密鑰以及因而存在兩個不同的私有密鑰。圖IB示出了安全密鑰管理方法的第二階段，S卩，認證密鑰交換。在該實施例中，認證密鑰交換是基于IBAKE(以上在章節(jié)I. B.中描述的)。由于在第一方和第二方之間的消息交換的優(yōu)選格式是基于多媒體因特網(wǎng)密鑰(MIKEY)格式，因此圖IA和圖IB的整個安全密鑰交換協(xié)議在此被稱為MIKEY-IBAKE協(xié)議。再次假定左邊的設(shè)備是發(fā)起方或發(fā)起者102-1，而右邊的設(shè)備是響應方或響應者102-R。認證密鑰交換的步驟遵循與IBAKE協(xié)議類似的步驟。假定通過使用如以上在章節(jié)I中描述的散列函數(shù)來計算發(fā)起者的公共密鑰I_PK。 類似地，以類似的方式來計算響應者的公共密鑰R_PK。記住發(fā)起者和響應者的私有密鑰分別是 I_SK 和 R_SK。也就是說，假設(shè) H1 (Initiator_ID) = I_PK 和 H1 (Responder_ID) = R_ 1 是與公共密鑰相對應的橢圓曲線上的相應點。假設(shè)a是由發(fā)起者102-1選擇的隨機數(shù)，并且假設(shè)b是由響應者102-R選擇的隨機數(shù)。在102-1和102-R之間的協(xié)議交換包括以下步驟在步驟110中，發(fā)起者102-1計算第一隨機密鑰分量aP (即，在E上使用加法定律， P與其自身相加a次作為E上的點)，使用響應者的公共密鑰(R_PK)來加密第一隨機密鑰分量，并且將其傳送給響應者102-R。在該步驟中，加密指的是以上在子章節(jié)I. A.中描述的基于身份的加密。注意到在步驟110中，還包括在已加密的消息中的是發(fā)起者和響應者的身份(分別是I—ID和R_ID)。在接收到已加密的消息時，響應者使用(在圖IA中獲得的)其私有密鑰來解密該消息并且獲得aP。隨后，在步驟112中，響應者計算第二隨機密鑰分量bP，使用發(fā)起者的公共密鑰來加密該對laP，bP}，并且然后將該對傳送給發(fā)起者。再者，在步驟112中已加密的消息包括發(fā)起者和響應者的身份(分別是I_ID和R_ID)。在從步驟112接收到該消息時，發(fā)起者使用(在圖IA中獲得的)其私有密鑰來解密該消息并且獲得bP。隨后，在步驟114中，發(fā)起者使用響應者的公共密鑰來加密bP并且將其發(fā)送回給響應者。再者，在步驟114中已加密的消息包括發(fā)起者和響應者的身份(分別是 I_ID 和 R_ID)。在步驟116中，響應者向發(fā)起者發(fā)送使用發(fā)起者的公共密鑰來加密的驗證消息。在此之后，發(fā)起者和響應者都計算abP，作為在經(jīng)由多媒體通信系統(tǒng)的媒體平面 (應用層)的呼叫會話期間與彼此安全通信要使用的安全呼叫會話密鑰。觀察到，發(fā)起者102-1隨機地選擇a，并且在協(xié)議交換的第二步驟中接收到bP。這允許發(fā)起者通過將bP與其自身相加a次來計算abP。相反地，響應者102-R隨機地選擇b， 并且在協(xié)議交換的第一步驟中接收到aP。這允許響應者通過將aP與其自身相加b次來計算abP。還注意到。a是隨機的但aP卻不提供關(guān)于a的任何信息。因此，aP被認為是基于由發(fā)起者所選擇的隨機秘密的密鑰的分量。類似地，b是隨機的但bP卻不提供關(guān)于b的任何信息。因此，bP被認為是基于僅響應者知道的隨機秘密的密鑰的分量。現(xiàn)在參考圖2，圖示了 MIKEY-IBAKE協(xié)議的擴展。應當明白，由于這是對上述 MIKEY-IBAKE協(xié)議的擴展，因此出于簡單起見，沒有重復MIKEY_IBAKE協(xié)議的所有特征。在該特定實施例中，圖2圖示了分路。分路是將請求遞送到多個位置。這可以例如當響應者具有不止一個通信(計算)設(shè)備(他/她可以在該設(shè)備上參與多媒體呼叫會話)時發(fā)生。 分路的一個例子是當一方具有桌面電話、個人計算機(PC)客戶端和移動手機時，它們?nèi)急慌渲靡员銋⑴cMIKEY-IBAKE協(xié)議。一般而言，分路是多媒體會話發(fā)起協(xié)議的特征，其使得來話呼叫能夠同時對若干個擴展進行振鈴。然后，應答的第一電話將控制該呼叫。因而，如圖2所示，響應方具有與其相關(guān)聯(lián)的兩個設(shè)備102-R1和102-R2。因而，如圖所示，設(shè)備102-R1具有公共密鑰R1_PK和秘密密鑰R1_SK。而且，設(shè)備102-R1知道響應方的公共和私有密鑰，R_PK和R_SK。類似地，設(shè)備102-R2具有公共密鑰R2_PK和秘密密鑰 R2_SK。而且，設(shè)備102-R2知道響應方的公共和私有密鑰，R_PK和R_SK。在分路情形中，MIKEY-IBAKE協(xié)議步驟210、212、214和216基本上與圖IB的一般情境中的MIKEY-IBAKE協(xié)議步驟110、112、114和116相同，但是有下面的例外。注意到，因為在步驟210中由設(shè)備102-1發(fā)送的消息是用RJ3K來加密的，所以設(shè)備Rl和R2都可以解密該消息(因為它們都具有R_SK)。然而，假定響應方當前與設(shè)備R2而不是設(shè)備Rl相關(guān)聯(lián)，那么在步驟212中，返回消息包括由R2依照IBAKE來計算的隨機密鑰分量Id2P(其中1^2 是由R2選擇的隨機數(shù))。而且，在步驟212中已加密的消息包括發(fā)起者、響應者和設(shè)備R2 的身份(分別是I_ID，R_ID和R2_ID)。設(shè)備102-1使用其私有密鑰來解密從R2接收到的消息，以便獲得b2P和在該消息中包括的身份。發(fā)起者因而標識出在步驟212中的消息來自R2。依照MIKEY-IBAKE協(xié)議， 發(fā)起者然后在步驟214中發(fā)送包括Id2P、I_ID、和R2_ID的消息。該消息是使用R2的公共密鑰來加密的。注意到這無法由Rl來解密，因為Rl僅具有R_SK和R1_SK，而沒有R2_SK。 步驟216是與圖IB中的步驟116類似的驗證消息。然后可以在設(shè)備102-1和設(shè)備102-R2 處將呼叫會話密鑰計算為ab2P。圖3圖示了 MIKEY-IBAKE協(xié)議對重定目標特征(retargeting feature)的擴展。 應當明白，由于這是對上述MIKEY-IBAKE協(xié)議的擴展，因此出于簡單起見，沒有重復MIKEY_ IBAKE協(xié)議的所有特征。重定目標或重定向是以下情形通信系統(tǒng)中的一個或多個功能元件決定將呼叫重定向到不同的目的地。這種重定向會話的決定可以出于不同的原因由多個不同的功能元件并在會話建立中的不同點處進行。這也被稱為呼叫轉(zhuǎn)發(fā)。圖3的例子示出了進行重定向確定的應用服務器302。在分路情形中MIKEY-IBAKE 協(xié)議步驟310、312、314和316基本上與圖IB的一般情境下的MIKEY-IBAKE協(xié)議步驟110、 112、114和116相同，但是有下面的例外。設(shè)備102-1在步驟310中在該協(xié)議中發(fā)送第一消息，預計其去往設(shè)備102-R1 (用 Rl的公共密鑰來加密該消息)。然而，功能元件302作出決定在310中的消息應當被重定向到設(shè)備R2，參見步驟310’。在此之前，或者與其相結(jié)合地，假定R2經(jīng)由該功能元件在步驟308所發(fā)送的消息中接收到Rl的私有密鑰。使用R2的公共密鑰來加密從Rl發(fā)送到R2 的消息。因而，功能元件302無法解密在308中的該消息，但是R2可以在310’中解密該消息并且在步驟312中對發(fā)起者做出響應。從這一點來看，步驟312、314和316與圖2的分路情形中的步驟212、214和216相同。圖4A示出了 MIKEY-IBAKE協(xié)議的遲延遞送擴展。應當明白，由于這是對上述 MIKEY-IBAKE協(xié)議的擴展，因此出于簡單起見，沒有重復MIKEY_IBAKE協(xié)議的所有特征。遲延遞送是使得會話內(nèi)容在其被發(fā)送時無法被遞送到目的地的一類服務(例如，目的地用戶當前不在線)。然而，發(fā)送者希望在接收者一變得可用時網(wǎng)絡(luò)就遞送該消息。遲延遞送的一個例子是語音郵件。在圖4A中，假設(shè)A是設(shè)備102-1，B是102-R，設(shè)備402是諸如應用服務器的功能元件，并且MB是與B相關(guān)聯(lián)的郵箱102-MB (更一般地，是臨時目的地)。在步驟401中，A向B發(fā)送包括已加密的第一隨機密鑰分量(xP)的第一消息。在 A處計算第一隨機密鑰分量，并且使用B的公共密鑰來加密第一消息。功能元件402確定B不可用，并且在步驟402中將該第一消息轉(zhuǎn)發(fā)到MB。在步驟403中，MB向A發(fā)送包括由MB計算的已加密的第二隨機密鑰分量(yP)的第二消息。在步驟403中使用A的公共密鑰在MB處加密該消息。在步驟404中，功能元件 402將該消息發(fā)送到A。A使用由A從密鑰服務獲得的私有密鑰來解密來自MB的消息，以便獲得第二隨機密鑰分量。A標識出在步驟404中接收到的消息來自MB (由于MB的身份被包括在該消息中)。在步驟405中，A(在步驟406中經(jīng)由功能元件)向MB發(fā)送包括已加密的隨機密鑰分量對的第三消息，所述隨機密鑰分量對是根據(jù)第一隨機密鑰分量(χΡ)和第二隨機密鑰分量(yP)來形成的，并且使用MB的公共密鑰在A處進行加密。該第三消息還包括在A處計算的并且使用B的公共密鑰在A處加密的已加密隨機秘密密鑰(SK)0經(jīng)由步驟407和步驟408，MB向A確認接收。MB無法解密該消息的后面部分(因為是使用B的公共密鑰來對其加密的并且MB并不具有B的私有密鑰)，并且因而無法知道sK。在B和MB之間的相互認證操作之后，經(jīng)B請求，MB向B提供已加密的隨機秘密密鑰(sK)。這在步驟409和410中示出。該秘密密鑰然后由B用來獲得由A留在B的郵箱中的內(nèi)容(例如，語音消息)。在圖4A的遲延遞送的變體中，如圖4B中所示，假定沒有實施認證密鑰協(xié)定協(xié)議， 而是在第一消息中，A發(fā)送在A處計算的并且在A處使用B的公共密鑰來加密的已加密隨機秘密密鑰(sK)(步驟411)。功能元件402(其已經(jīng)確定B不可用)將第一消息轉(zhuǎn)發(fā)到MB(步驟412)，MB對其進行確認(步驟413和414)。稍后，B可以按照與上述相同的方式從MB中檢索秘密密鑰(步驟415和416)。圖5示出了 MIKEY-IBAKE協(xié)議的又一擴展。再次應當明白，由于這是對上述 MIKEY-IBAKE協(xié)議的擴展，因此出于簡單起見，沒有重復MIKEY_IBAKE協(xié)議的所有特征。圖 5中的擴展涉及在多媒體通信系統(tǒng)中交換的消息的合法攔截的概念。合法攔截的概念是基于當執(zhí)法機構(gòu)需要能夠“偵聽”一方或多方的通信時的情形。在一個方法中，執(zhí)法機構(gòu)可以簡單地通過搜查證來獲得102-1和102-R的私有密鑰，并且在密鑰商定協(xié)議期間扮演有效的“中間人”，然后接入(tap into)到業(yè)務中。在圖5中示出的另一個方法中，執(zhí)法服務器(Li服務器)502與發(fā)起者的KMS (KMS1) 和響應者的KMS(KMSk) —起起作用，以便合法地攔截在設(shè)備102-1和設(shè)備102-R之間發(fā)送的消息。雖然圖5示出了用于LI服務器、KMS1和KM&的分離的服務器，但是應當理解，多媒體通信系統(tǒng)中的一個功能元件(例如，攔截服務器)可用于實現(xiàn)KMS和攔截功能。因此，實現(xiàn)了如以上在圖IA和IB的情境下所描述的MIKEY_IBAKE協(xié)議。然而，LI 服務器針對被發(fā)送到響應者的消息來模仿發(fā)起者，并且針對被發(fā)送到發(fā)起者的消息來模仿響應者。例如，考慮當LI服務器模仿響應者時的消息流。假定102-1發(fā)送希望由102-R接收的第一消息，其包括已加密的第一隨機密鑰分量。第一消息被LI服務器攔截。LI服務器然后計算第二隨機密鑰分量并且將包括了已加密的隨機密鑰分量對的第二消息發(fā)送到 102-1。隨機密鑰分量對是根據(jù)第一隨機密鑰分量和在LI服務器處計算的第二隨機密鑰分量來形成的。使用102-1的公共密鑰在LI服務器處加密第二消息。
使用由102-1從密鑰服務獲得的私有密鑰來解密第二消息，以便獲得第二隨機密鑰分量。設(shè)備102-1然后發(fā)送希望由102-R接收的包括第二隨機密鑰分量的第三消息，但是其被LI服務器攔截。因而，LI服務器能夠計算設(shè)備102-1所計算的相同的安全密鑰。應當明白，LI服務器還模仿發(fā)起者(102-1)在認證密鑰協(xié)定操作期間發(fā)送和接收消息，從而使得響應者(102-R)與LI服務器建立響應者認為是發(fā)起者同意的(但實際上是 Ll服務器同意的)安全密鑰。應當理解，上述MIKEY-IBAKE協(xié)議特征中的一個或多個特征可以擴展到會議系統(tǒng)情形。圖6A至圖6C中描述了這樣的擴展。一般的假設(shè)是中繼了多方通信(例如，會議橋)的會議服務器(更一般地，會議管理元件)并不知道群組密鑰，盡管所有的用戶都取得了相同的群組密鑰。該假設(shè)存在例外，即，在對等會議中，當充當會議橋的計算設(shè)備實質(zhì)上也是參與該會議的一方時。如圖6A所示，假定多方會議600包括會議服務器和用戶(各方)1至N，其中，按照用戶設(shè)法加入會議的順序來分派用戶編號，即，依序地1，2，3，... N。在步驟602中，每個用戶單獨地與會議服務器執(zhí)行IBAKE協(xié)議。假設(shè)& = ^P是在與服務器認證期間由用戶“I”發(fā)送到會議服務器的值。記住af是依照IBAKE由該方所計算的隨機密鑰分量。在認證成功之后，在步驟604中，會議服務器(廣播或單獨單播地)將集合IaiPl 發(fā)送給每個用戶。集合IaiPl因而是包括由各方中的每一方所計算的隨機密鑰分量。在步驟606中，每個用戶單獨地將Xi = a, (BitlP-Bi^1Pj發(fā)送回給會議服務器。注意到AlawP-^v1Pl是隨機群組密鑰分量，其中，由每一方經(jīng)由基于以下內(nèi)容的計算方法來計算隨機群組密鑰分量在密鑰認證操作期間由該方所使用的隨機數(shù)，以及由設(shè)法參與會議的兩方或更多方中的其它方的子集計算的隨機密鑰分量。在該實施例中，用于給定方的隨機群組密鑰分量hk+iP-aHP}被這樣計算，即， 是由給定方選擇的隨機數(shù)，ai+1P是由在會議排序中就在給定方之后的一方發(fā)送到服務器的隨機密鑰分量，Bi^1P是由在會議排序中就在給定方之前的一方所發(fā)送的隨機密鑰分量，并且P是選自與基于身份加密的密鑰認證操作相關(guān)聯(lián)的群組的點(例如，如上所述選自橢圓曲線的點)。在步驟608中，會議服務器(廣播或單獨單播地)然后與每一個人共享集合{XJ。 也就是說，集合{XJ是包括由各方所計算的隨機群組密鑰分量的集合。在步驟610中，每一方均可以計算用于在通過會議服務器與每個其它方的通信中使用的相同的群組密鑰。群組密鑰被計算如下=Nai (Zh) +(N-I)· · · +X"，其中N表示設(shè)法參與會議的各方的總數(shù)，a,表示由給定方選擇的隨機數(shù)，Zi表示由給定方計算的隨機密鑰分量，&表示由給定方計算的隨機群組密鑰分量，并且i表示在N方會議中對于給定方的會議排序的編號，其中當i = 1時，i-1 = N，并且當i = N時，i+Ι = 1。如上所述，會議服務器不是會議中的參與方，并且由此不能計算群組密鑰。然而， 在對等情形下，會議服務器是會議呼叫中的參與方，并且由此需要能夠計算群組密鑰。應當明白，會議服務器實施與設(shè)法參與會議的每一方的相互認證操作。僅當滿足至少兩個條件時，會議服務器才批準給定方到會議(i)給定方被會議管理元件認證；以及 ( )給定方被確認屬于會議授權(quán)列表。而且，依照以上MIKEY-IBAKE協(xié)議，設(shè)法參與會議的各方以及會議服務器從一個或多個密鑰管理服務(KMS)獲得相應的私有密鑰。
圖6B圖示了如何將新的會議參與者(用戶N+1)添加到正在進行的會議，因而得到了經(jīng)修改的會議600’。在步驟612中，用戶N+1與會議服務器執(zhí)行IBAKE。假設(shè)ZN+1 = aN+1P是在與服務器認證期間由用戶“N+1”發(fā)送到服務器的值。在用戶N+1的認證成功之后，在步驟614中， 會議服務器宣告批準新的用戶N+1并且(廣播或單獨單播地)將包括ZN+1的集合IaiPl發(fā)送給每一個人。在步驟616中，用戶1、N、N+1將Xi = Bi (BitlP-Bi^1Pj發(fā)送回給服務器；交替地，他們?nèi)伎梢詧?zhí)行該步驟。在步驟618中，會議服務器然后(廣播或單獨單播地)與每一個人共享包括Xiw的集合{XJ。然后在步驟620中重新計算群組密鑰(Ν+1) (Ζη)+ (N)Xi+(N-I) Xi+1+. . . . +Χ"。觀察到，群組密鑰在批準新用戶之后發(fā)生改變。圖6C圖示了會議參與者如何退出正在進行的會議，因而得到了經(jīng)修改的會議 600”。假定用戶3退出呼叫(應當明白，選擇用戶3僅是示例)。在步驟622中，會議服務器(廣播或單獨單播地)宣告哪一個用戶退出了呼叫。在步驟624中用戶排序發(fā)生改變。用戶1和2保持相同。對于大于或等于4的所有i，用戶i變?yōu)橛脩鬷-Ι。在步驟626 中，用戶4 (其現(xiàn)在是用戶3)重新計算&并且與會議服務器共享該結(jié)果(contribution)。 在步驟6 中，會議與所有參與者共享集合{XJ。在步驟630中，參與者重新計算群組密鑰 (N-Dai (2^) + (^2)^+(^3)^+. . . . +Χ"。再次觀察到，在參與者退出呼叫之后，群組密鑰發(fā)生改變。本發(fā)明的原理還提供了對以上描述的會議管理技術(shù)的擴展。該擴展涉及對會議消息的合法攔截。假設(shè)會議系統(tǒng)中存在N個參與者。假定參與者N“受污染(tainted) ”并且執(zhí)法機構(gòu)已經(jīng)獲得許可證來接入到去往和來自參與者N的呼叫中。選擇宣稱參與者N受污染僅用于說明，并且使得描述易于理解，并且該解決方案決不限于將第N個用戶宣稱為受污染用戶。在會議呼叫之前，LI服務器(回想在圖5中)接洽與參與者N相對應的KMS并且獲得參與者N的私有密鑰。這將允許LI服務器在群組密鑰交換過程期間假裝是參與者N 并且執(zhí)行圖6A中的所有步驟，除了參與者N的貢獻被替換為來自LI服務器的貢獻。特別地，LI服務器用L和Xu來替換\和\。其余的參與者將不知道該差別，并且將計算群組密鑰，稱其為GK’。接下來，LI服務器與會議服務器一起工作，并且在與參與者N的所有通信中將Z1 和&替換為、和1。這將意味著參與者N將計算出與GK’不同的群組密鑰。將該新的密鑰稱為GK”。注意到，在以上的步驟中，對于任何參與者，LI服務器都會將τ、和\替換為L和 I，并且選擇i = 1僅用于說明。在建立呼叫之后，將使用GK’來加密來自參與者1至N-I的任何通信。由于LI服務器知道GK’，因此它然后可以攔截該通信，對其進行解密，之后它將用GK”對其進行重新加密，并將其發(fā)送給參與者N。相反地，將使用GK”來加密來自參與者N的任何通信，其將被 LI服務器攔截，然后使用GK”進行解密，使用GK’重新加密，并且發(fā)送到參與者1至N-I。
III. IMS 實施例在下面的章節(jié)中，MIKEY_IBAKE的以上一般原理及其擴展被應用于IP多媒體子系統(tǒng)(IMQ環(huán)境。也就是說，在該章節(jié)中，多媒體通信系統(tǒng)被認為是IMS網(wǎng)絡(luò)。例如，在3GPP 技術(shù)規(guī)范 TS 23. 218、TS 23. 228、TS24. 228、TS 24. 229 和 TS 24. 930 中描述了 IMS 標準， 通過引用的方式將其公開內(nèi)容合并于此。首先描述用于IMS媒體平面安全性的架構(gòu)框架，具體針對密鑰管理，基于這些可以導出各種特征和使用情況。該解決方案的核心是基于身份的加密(IBE)概念，類似于RFC 5091、RFC 5408和 RFC 5409，通過引用的方式將其公開內(nèi)容合并于此。然而，這些RFC并沒有提供認證并且存在固有的密鑰托管問題。在此通過擴展基本IBE以便包括基于身份的認證密鑰交換(IBAKE)協(xié)議(其提供相互認證)來解決這些問題，消除了被動密鑰托管，并且提供了密鑰的完美保密。雖然IBAKE是基本協(xié)議構(gòu)造，但這里使用MIKEY作為用于密鑰遞送的協(xié)議容器。關(guān)于本發(fā)明的IMS解決方案框架的一個關(guān)鍵思想是重用包括KMS的所建議的架構(gòu)，但是明顯地并不要求這些KMS服務器總是在線。換句話說，在所建議的框架中，KMS是定期(例如，一個月一次)與終端用戶通信的離線服務器，以便創(chuàng)建基于安全身份的加密框架，而終端用戶客戶端之間的在線事務(針對媒體平面安全性)是基于允許參與的客戶端在不對稱的基于身份的加密框架中交換密鑰分量的IBAKE框架。該框架除了消除被動托管之外，還允許終端用戶客戶端(在IMS媒體平面層)彼此相互認證并提供完美的前向和后向保密。觀察到，KMS到客戶端的交換被保守地(sparingly)使用(例如，一個月一次)_因此不再要求KMS是高可用性服務器，并且特別地，不同的KMS不必(跨運營商邊界)彼此通信。此外，假定使用不對稱的基于身份的加密框架，則消除了對高成本公共密鑰基礎(chǔ)設(shè)施 (PKI)以及有關(guān)證書管理和撤回的所有操作成本的需要。另外，各種IMS媒體平面特征得到安全的支持-這包括安全分路、重定目標、遲延遞送、預編碼的內(nèi)容、媒體剪輯以及匿名性。該解決方案的擴展實現(xiàn)了安全會議應用，其中IMS會議應用服務器認證用戶進入到呼叫，但是該呼叫的所有參與者(在每個人的貢獻下)決定群組密鑰，而會議服務器自身卻不知道該群組密鑰。此外，該群組密鑰可以被修改以便反映新的參與者以及退出呼叫的參與者。基于IMS的密鑰管理框架的附加特征是盡管消除了被動密鑰托管，但是它支持在使用主動托管概念的執(zhí)法情況下對安全性憑證進行合法共享。圖7提供了在IMS媒體平面中的示例性端到端密鑰交換協(xié)議中所涉及的示意性架構(gòu)以及實體。應當明白，由于IMS架構(gòu)是公知的，因此沒有詳細描述圖7中所示的功能組件。 可以參考用于詳細解釋它們的功能的IMS標準。注意到，如已知的，CSCF指的是呼叫會話控制功能，由此，P-CSCF是代理CSCF并且S-CSCF是服務CSCF。NAF指的是網(wǎng)絡(luò)應用功能。在圖示的情形中，兩個支持IMS的終端用戶電話參與了端到端(e2e)密鑰交換以便保證應用層中的通信安全。注意到，該圖示包括在UE(用戶設(shè)備)與KMS之間的離線事務以及通過IMS的在UE之間的在線事務。觀察到，UE和KMS共享預配置的安全性關(guān)聯(lián)，其中，用戶可以與密鑰管理服務器建立安全連接，并且其中提供了相互認證。在3GPP系統(tǒng)的情境中的一個自然例子是使用廣義的自舉架構(gòu)(參見例如3GPP TS 33. 220，通過引用的方式將其公開內(nèi)容合并于此)。在圖 7中，通過BSF(自舉服務器功能)來啟用在KMS和UE之間的事務，并且記住該事務被保守地執(zhí)行(例如，一個月一次)。注意到，如果GBA不可用，則諸如具有預共享密鑰或證書的 IKEv2這樣的其它類型的憑證(參見例如IETF RFC4306，通過引用的方式將其公開內(nèi)容合并于此)可用于建立在用戶和KMS之間的該相互認證。在該事務期間，UE呈現(xiàn)其預訂憑證，之后KMS生成(在IBAKE中使用的)私有密鑰集合。如果該事務一個月執(zhí)行一次，那么KMS可以選擇為每一天生成一個密鑰。密鑰的數(shù)目以及該交換的頻率是策略的問題，并且其可以與預訂相關(guān)。該靈活性對于預付費消費者尤其有用。注意到，不是單個KMS，而可能涉及兩個不同的KMS ；—個用于用戶A，S卩，KMS_A，而一個用于用戶B，S卩，KMS_B。然而，KMS_A和KMS_B不必彼此通信。該情形尤其適用于運行商之間的情形。現(xiàn)在給出在IMS情境下MIKEY-IBAKE中所涉及的交換的簡短總結(jié)。假設(shè)A、B是正在嘗試認證和商定密鑰的兩個用戶。同時，A和B表示它們的對應身份，按照定義其還表示它們的公共密鑰。假設(shè)H1 (A) = * ^) = ( 是與公共密鑰相對應的橢圓曲線上的相應點。實際上，也可以將A和( 稱為公共密鑰，因為在身份與通過應用H1所獲得的曲線上的點之間存在一對一的對應性。假設(shè)X是由A選擇的隨機數(shù)，并且假設(shè)y是由B選擇的隨機數(shù)。下面的加密指的是如上在章節(jié)I中所描述的基于身份的加密?；贗MS的MIKEY-IBAKE協(xié)議交換包括以下步驟(參考圖7中示出的組件)1.屬于用戶A的IMS UE向BSF自舉以便能夠與充當NAF的KMS建立安全連接。 這允許BSF認證該用戶并且該用戶間接認證KMS。如果無法使用GBA，則IMS UE連接到KMS 并對其進行認證，并且基于預先建立的安全性關(guān)聯(lián)來建立共享密鑰。2. IMS UE從事與KMS的MIKEY交換，并且請求秘密密鑰(或者多個秘密密鑰，例如用于每一天的一個秘密密鑰)。3. KMS為用戶A的IMS UE生成(一個或多個)媒體秘密密鑰并且將其發(fā)送給用戶 A04.用戶A的IMS UE計算xP ( S卩，在E上使用加法定律，將P與其自身相加χ次作為E上的點)，使用B的公共密鑰對其進行加密，并且將其傳送給用戶B的IMS UE。5. IMS核心檢測到INVITE并且按照以下方式對其進行處理網(wǎng)絡(luò)功能如果被授權(quán)則可以獲取會話密鑰。特別地，該步驟僅適用于支持滿足任何合法攔截要求所需要的主動托管特征。6.用戶B的IMS UE接收包括已加密的xP的INVITE。用戶B的IMSUE解密該消息并獲得xP。隨后B計算yP，并且使用用戶A的IMS UE的公共密鑰來加密該對{xP，yP}， 然后在響應消息中將其傳送到A。7.在收到該消息時，用戶A的IMS UE解密該消息并獲得yP。隨后用戶A的IMS UE使用B的公共密鑰來加密yP，并且在響應確認消息中將其發(fā)送回給B。之后，A和B都計算xyP作為會話密鑰。8.此時，用戶B的IMS UE接受該邀請和對媒體安全性的使用。觀察到A隨機地選擇X，并且在協(xié)議交換的第二步驟中接收到y(tǒng)P。這允許A通過將yP與其自身相加χ次來計算xyP。相反地，B隨機地選擇y，并且在協(xié)議交換的第一步驟中接收到χΡ。這允許B通過將χΡ與其自身相加y次來計算xyP。從MIKEY-IBAKE協(xié)議產(chǎn)生的一些有利屬性如下。相互認證。觀察到，使用B的公共密鑰來加密在步驟4和7中的有效載荷的內(nèi)容。 因此B并且僅是B可以解密這些消息。類似地，在步驟6中的消息的內(nèi)容可以由A并且僅可由A來解密。還注意到，步驟6和7允許B和A(通過證明消息被正確解密)進行彼此認證。該新穎的特征允許A和B在沒有任何在線服務器或證書機構(gòu)的幫助下相互認證。完美保密。觀察到，χ和y是隨機的。因此會話密鑰xyP是新鮮的并且與過去或未來的事務沒有關(guān)系。消除了被動托管。觀察到，雖然KMS(或一對KMS)可以對交換中的消息進行解密，但是在給定χΡ和yP的情況下卻難以確定xyP。該困難性假定取決于橢圓曲線上的 Diffie-Hellman問題。還注意到，用于IBE的曲線是特定于KMS的，并且此外不需要與用來生成會話密鑰的曲線相同。該靈活性提供了大范圍的選擇性，并且還消除了 KMS之間所需的任何協(xié)調(diào)。身份管理。如上所述，為了加密消息，發(fā)送者使用接收者的公共密鑰，該公共密鑰是使用接收者的身份(或身份之一)來生成的。接收者的身份可以采用指定了特定用戶、 一組用戶或任何用戶的格式。用戶和用戶群組的命名可以遵循標準的IMS管理并且可以通過使用通配符來進行擴展。在涉及群組應用的某些情形下，可能自然的是采用以下策略 允許該群組中的所有接收者使用與該特定用戶組的身份相對應的秘密密鑰。例如，對于企業(yè)用戶，可能自然的是默認與企業(yè)的身份相對應的秘密密鑰被分發(fā)到所有的企業(yè)用戶。 注意到，由于基于身份的加密的屬性，因此，盡管屬于一個群組的所有用戶都可能擁有該群組的秘密密鑰，但是不是所有用戶都可以獲得在發(fā)送者與屬于該相同群組的某個其它用戶之間所建立的會話密鑰。為了確保實施策略，還需要公共用戶身份可以被安全地綁定到 IMSUE。換句話說，對用戶所使用的身份來說，重要的是針對KMS來對公共身份(的集合) 進行認證?，F(xiàn)在討論MIKEY-IBAKE協(xié)議對于各種基于IMS的使用情況的那些情形的擴展。注意到，在章節(jié)II中總體上描述了這些擴展。下面的描述是在IMS環(huán)境的情境下。A.通過主動托管的合法攔截(Li)為了能夠提供被攔截通信的清楚備份，必須滿足下面的條件1.必須有可能攔截業(yè)務(信令和媒體這兩者)。2.實際業(yè)務保護所使用的會話密鑰必須可用。為了使會話密鑰可用，要求KMS功能/服務。如上所述，業(yè)務保護所使用的實際會話密鑰是在發(fā)送者和接收者之間生成的，因而不為KMS所知。因此，需要主動托管解決方案。在該情形下，對于KMS來說，為了獲得用戶A和B之間的會話密鑰，需要在其自身與用戶A之間建立有效會話密鑰并且在其自身與用戶B之間建立另一同時的有效會話。對于A，KMS假裝是B，并且相反地，對于B，KMS假裝是A。由KMS所扮演的該“中間人”角色被稱為主動托管，并且類似于在PKI環(huán)境(其中證書機構(gòu)生成“假證書”并處于交換的中間)中所使用的方法。在常規(guī)CA中使用的技術(shù)和本發(fā)明針對主動托管的方法之間的差別在于KMS不必生成假密鑰。
在經(jīng)由歸屬網(wǎng)絡(luò)路由的信令業(yè)務的情況下，對歸屬網(wǎng)絡(luò)中的信令業(yè)務的攔截可以在(一個或多個)SIP (會話發(fā)起協(xié)議)服務器處完成。然后，該信令業(yè)務需要被路由到合適的KMS，以便該KMS與對應的用戶建立所需要的會話密鑰。在漫游情形下，因為在IMS UE 和P-CSCF之間通常對SIP信令業(yè)務進行機密性保護，并且考慮到在當前部署中P-CSCF位于歸屬網(wǎng)絡(luò)中，所以在受訪網(wǎng)絡(luò)中SIP信令僅以加密格式在承載級處可用。對于漫游情形，雖然已加密的SIP信令和內(nèi)容將總是可用，但是為了攔截SIP信令并解密通信的內(nèi)容，在受訪網(wǎng)絡(luò)和處理KMS的實體之間必須存在操作間協(xié)定。通常，KMS將駐留在歸屬網(wǎng)絡(luò)中，從而使得對于由受訪網(wǎng)絡(luò)所實施的Li，需要與歸屬網(wǎng)絡(luò)協(xié)作。與LI標準一致，當在加密中不涉及VPLMN(受訪的公共陸地移動網(wǎng)絡(luò))時，在 VPLMN中僅已加密的內(nèi)容將可用于Li。B.在不同的KMS域中的用戶在不同的KMS域中的用戶將通過不同的KMS來生成它們的秘密密鑰。結(jié)果，不同集合的公共參數(shù)(例如，密碼材料)可用于為不同的KMS域中的用戶生成公共密鑰和秘密密鑰。為了確保適當?shù)募用?解密，發(fā)送者和接收者需要知道由每一側(cè)使用的確切公共參數(shù)。然而，如果一個KMS域中的用戶需要向另一個KMS域中的用戶建立安全呼叫，則所涉及的KMS并不需要協(xié)作。如在任何基于身份的密碼協(xié)議中或者針對該問題的任何公共密鑰協(xié)議那樣，可以安全地假定交換所需要的公共參數(shù)是公共可用或進行公共交換的。C.端到中間(end-to-middle)的情形在端到中間的情形中，媒體保護是在IMS UE和網(wǎng)絡(luò)實體之間。在從IMS UE發(fā)起呼叫時的情形下，呼叫的建立將遵循與用于端到端保護的呼叫相同的原理。進行發(fā)起的IMS UE使用網(wǎng)絡(luò)實體的身份(例如，MGWC-媒體網(wǎng)關(guān)控制)，以便如上所述來加密xP，并且將其與INVITE —起進行發(fā)送。MGWC攔截該消息，并且按照進行接收的IMS UE會實施的相同方式來生成yP。然后，MGffC建立MGW以便具有針對IMS UE的媒體安全性。在PSTN(公共交換電話網(wǎng)絡(luò))中對媒體業(yè)務進行簡單轉(zhuǎn)發(fā)。對于針對IMS UE的來話呼叫，MGWC檢查被注冊用于所希望的接收者的至少一個終端是否已經(jīng)注冊了媒體安全性能力和偏好。如果沒有能夠進行媒體保護的終端，則簡單轉(zhuǎn)發(fā)該呼叫。否則，MGWC選擇y并且生成yP。然后，MGWC(使用IMS UE身份)將已加密的 yP插入到INVITE中，并且針對在MGW和IMS終端之間的媒體業(yè)務發(fā)起對MGW中的媒體安全性的使用。D.密鑰分路在該章節(jié)中，對基于IMS的MIKEY-IBAKE的情況討論了分路?；叵氲揭陨显趫D2 的情境下在總體上描述了分路。分路是將請求(例如，INVITE消息)遞送到多個位置。這發(fā)生在不止一次注冊了單個IMS用戶時。分路的例子是當用戶使得桌面電話、PC客戶端和移動手機全都用相同的公共身份進行注冊的時候。在下面描繪的以及在圖8的步驟1至8的情境下所示出的例子中，假定用戶B的 IMS UE具有用單個公共用戶身份B注冊的多個聯(lián)系地址。換句話說，Bl和B2都獲得與公共身份B相對應的秘密密鑰。在這種情況下，如果用戶A的IMS UE想要聯(lián)系用戶B的IMS UE，則請求會被遞送到Bl和B2這二者。假定B2對呼叫做出響應，那么B2首先使用與身份 B相關(guān)聯(lián)的秘密密鑰來解密所接收到的消息。然后，B2選擇隨機的y并向A發(fā)送包括了使用A的公共身份來加密的yP及其身份B2的消息。在接收到該消息時，用戶A將其解密，意識到它正在與用戶B2通信，并且發(fā)送響應確認消息，該響應確認消息包括使用B2的公共身份來加密的所接收到的yP。觀察到，Bl能夠解密從用戶A接收到的使用B的公共身份來加密的消息，因此能夠獲得xP。然而，其不能解密從B2發(fā)送的消息，因為該消息是使用A的身份來加密的。因而，用戶Bl不能獲得yP。還注意到，即使Bl能夠獲得yP，它也仍然不能計算xyP。注意到， 在圖7中，(M)_X表明使用X的身份來加密消息M。E.重定向在該章節(jié)中，對基于IMS的MIKEY-IBAKE的情況討論了會話重定向(重定目標)。 回想到以上在圖3的情境下在總體上描述了重定向。會話重定向是以下情形功能元件決定將呼叫重定向到不同的目的地。會話重定向啟用了典型服務“無條件會話轉(zhuǎn)發(fā)”、“忙會話轉(zhuǎn)發(fā)”、“可變會話轉(zhuǎn)發(fā)”、“選擇性會話轉(zhuǎn)發(fā)”和“無應答會話轉(zhuǎn)發(fā)”。會話重定向存在兩種基本情形。在一種情形下，功能元件(例如，S-CSCF)決定使用SIP REDIRECT方法來重定向會話。換句話說，功能元件將新的目的地信息傳遞到始發(fā)方。 結(jié)果，始發(fā)方向功能元件所提供的重定向目的地發(fā)起新會話。對于MIKEY-IBAKE的情況，這意味著始發(fā)方將在重定向目的地的身份的情況下發(fā)起新會話。在第二種情形下，功能元件決定在不通知始發(fā)方的情況下重定向會話。常見情形是目的地用戶的S-CSCF確定會話要被重定向。在注冊期間由'Cx-pull'從HSS(歸屬訂戶服務器)獲得的用戶簡檔信息可以含有復雜的邏輯以及引起會話重定向的觸發(fā)器。在圖9的步驟1至8所描繪的例子中，在不失一般性的情況下，假定用戶B設(shè)置了會話轉(zhuǎn)發(fā)到用戶C。在該情況下，用戶B在其用戶簡檔中包括使用C的身份來加密的其秘密密鑰SK_B。因此，一旦S-CSCF從用戶A接收到消息并且判定該消息需要被重定向，則其在重定向到用戶C的消息中包括B的已加密的密鑰。在接收到該消息時，用戶C對秘密密鑰進行加密，并且進而對來自A的該消息進行加密。然后，用戶C選擇隨機的y并且向A發(fā)送包括了使用A的公共身份來加密的yP及其身份C的消息。在接收到該消息時，用戶A將其解密，意識到其正與用戶C進行通信，并且發(fā)送響應確認消息，該響應確認消息包括使用 C的公共身份來加密的所接收到的yP。在圖9中，(M)_X表明使用X的身份來加密消息M。F.遲延遞送在該章節(jié)中，對基于IMS的MIKEY-IBAKE情況討論了遲延遞送。從章節(jié)II想到 遲延遞送是使得會話內(nèi)容在其被發(fā)送時無法被遞送到目的地(例如，目的地用戶當前不在線或決定不應答該呼叫)的一類服務。然而，發(fā)送者希望在接收者一變得可用時網(wǎng)絡(luò)就遞送該消息。遲延遞送的典型例子是語音郵件。下面呈現(xiàn)了對基于IMS的MIKEY-IBAKE情況的遲延遞送的兩種基本情形?？梢苑祷貐⒖加糜诘谝磺樾蔚膱D4A和用于第二情形的圖4B。在第一種情形下，用戶A和B的郵箱在它們商定要用于解密打算遲延遞送的消息內(nèi)容的密鑰之前實施相互認證，而在第二種情形下不實施相互認證。在第一種情形下(再次，可以返回參考圖4A，其中功能元件402是IMS服務器)， 假定用戶A正在嘗試與用戶B取得聯(lián)系，用戶B當前不可用，因此該呼叫被轉(zhuǎn)發(fā)到B的‘語音郵箱’(更一般地，轉(zhuǎn)發(fā)到遲延遞送服務器)。遵循MIKEY-IBAKE協(xié)議，使用B的身份來加密由B的郵箱接收到的該消息，因此，B的郵箱將不能對其進行解密。B的郵箱選擇隨機的 y和計算yP，并且將IBE加密的yP及其身份發(fā)送到用戶A。用戶A認識到B沒有接收到該消息并且實際的接收者由于缺少其身份和xP而不能解密在第一步驟中發(fā)送的該消息。因此，該用戶發(fā)送含有全都使用B的郵箱身份來IBE加密的xP、yP、A的身份和B的郵箱身份的新消息。在接收到該消息時，B的郵箱接受“sK”作為用于針對B的消息的會話密鑰，并且將A的身份和xP返回給用戶A以便完成認證。觀察到，使用B的公共密鑰來加密sK ；因此郵箱B無法解密該消息和獲得“sK”。 隨后，當B在線并且檢查‘語音郵件’(檢查遲延遞送服務器)時，B可以從郵箱服務器獲得 sK的加密值。注意到，B可能必須與郵箱進行認證以便獲得密鑰-這可以基于已經(jīng)存在的現(xiàn)有認證機制。在第二種情形下(再次，可以返回參考圖4B，其中功能元件402是IMS服務器)， 相同的假定成立-用戶A正在嘗試與用戶B取得聯(lián)系，用戶B當前不可用，因此該呼叫被轉(zhuǎn)發(fā)到B的語音郵箱。然而，在這種情況下，B的郵箱和用戶A并不實施認證。相反，B的郵箱僅接受sK作為會話密鑰并且向用戶A返回OK消息以便對其進行確認。G.群組和會議呼叫在該章節(jié)中，MIKEY-IBAKE的密鑰管理協(xié)議被擴展到群組和會議呼叫。注意到，從 MIKEY-IBAKE協(xié)議產(chǎn)生的有利屬性因此在會議環(huán)境中得到實現(xiàn)?；叵氲揭陨显趫D6A至圖 6C的情境下總體上描述了會議。注意到，在圖10中IMS例子用于N = 3。在圖10的步驟1至18中描繪的基于IMS的情形下，假定存在邀請用戶到會議呼叫的會議服務器(AS/MRFC-應用服務器/多媒體資源功能控制器)。這可能是由于例如先前從另一用戶接收到的REFER請求導致的。備選方法會是將該功能委派給用戶之一(例如， 會議主席)。盡管圖10中沒有示出該備選方法，但是該方法將是類似的并且對群組密鑰的計算會是相同的。在下面的描述中，假定所有的消息都是使用合適的身份來進行IBE加密的(例如， 如果用戶Y在向用戶X發(fā)送消息M，那么使用X的身份來加密消息M)。在圖10中，這被表示為(M)_X，意味著使用X的身份來對消息M進行IBE加密。在與會議服務器的第一交換集合中，用戶ApA2和A3分別選擇隨機的 、 和 并且每個用戶Ai向會議服務器發(fā)送Wi = ^P15在第二交換集合中，會議服務器向每一個用戶發(fā)送所有的 Ρ，而每個用戶發(fā)送Zi = (SwP-^1P)。在最后的交換中，會議服務器向每個用戶發(fā)送所有的Zi。此時，所有會議參與者都能夠?qū)⑷航M密鑰計算如下=Ki = ^+2ζΛζι+ιο注意到,K1 = K2 = K30還注意到，雖然用戶ApA2和A3能夠生成群組密鑰，但是會議服務器不能，因為雖然它知道Zi和^，但是僅用戶單獨知道它們隨機選擇的％。出于簡單的原因，以上討論集中于三個會議呼叫參與者。然而，以上過程可以推廣到η個參與者。在η個參與者的情況下，群組密鑰被生成為Ki = Imi 1^+(11-1)2,+ (11-2) zi+1+. · · +Zi_2，其中Wi和Zi的定義如上。該協(xié)議的重要特征之一在于每當批準了新用戶或者現(xiàn)有用戶退出呼叫時，群組密鑰就改變。這確保新用戶在他們被添加到該呼叫之前不知道群組密鑰，并且過早離開呼叫的用戶不能接入在該呼叫之后的會話。觀察到，當添加新用戶并且在系統(tǒng)中已經(jīng)存在N個用戶時，那么在系統(tǒng)中將總共
22存在N+1個用戶。當將這些用戶放置于圓中時，那么與第N個用戶相鄰的用戶現(xiàn)在是第 (N+1)個用戶(而不是第一個用戶，這是在批準第N+1個用戶之前的情況)。批準新用戶的協(xié)議如下工作新用戶使用IBAKE來與會議服務器進行認證，類似于每一個用戶那樣。這允許用戶被批準(和被授權(quán)于該呼叫)，并且新用戶被確保(經(jīng)由會議服務器的認證)加入正確的會議。假設(shè)zN+1 = aN+1P是由新用戶在認證期間選擇的值。然后，會議服務器廣播或單播地向所有用戶發(fā)送針對所有i = 1至N+1的集合 {Zi}。這允許所有用戶了解該新用戶并確定他們的新鄰居。觀察到，鄰居列表僅對于用戶 1、N禾口 N+1發(fā)生改變。然后，用戶1、N和N+1計算它們的w的對應值，并且(單獨地)將其發(fā)送回給會議服務器。然后，服務器向所有用戶發(fā)送已更新的IwJ列表。然后，所有參與者使用與以上相同的關(guān)系(除了的新值以及將N替換為 N+1之外)來重新計算群組密鑰。當用戶退出會議呼叫時，那么不必執(zhí)行任何新的認證過程，但是群組密鑰發(fā)生改變。該過程如下工作會議服務器獲知退出會議呼叫的用戶。隨后，會議服務器向每一個人通知該事件以及與哪個用戶(不僅是身份，而且還包括順序)退出了該呼叫有關(guān)的信息。為了簡化該問題，會議服務器可以重新發(fā)送新的列
表 IzJ。這允許所有用戶重新發(fā)現(xiàn)他們的鄰居，并且(如果需要的話)重新計算Wi。留在該呼叫中的所有那些參與者(對其來說Wi發(fā)生改變)將向會議服務器通知他們的新值。然后，會議服務器發(fā)送已更新的列表{Wi}。然后，所有參與者使用與以上相同的關(guān)系(除了使用Wi的新值以及將N替換為N-I 之外)來重新計算群組密鑰。IV.說明性計算系統(tǒng)圖11圖示了根據(jù)本發(fā)明的按照適于實現(xiàn)兩個實體之間的安全密鑰管理協(xié)議的計算設(shè)備的形式的通信設(shè)備和網(wǎng)絡(luò)環(huán)境的廣義硬件架構(gòu)1100。雖然圖11僅示出了兩個實體，但是應當明白其它實體也可以具有相同的配置。因而，就以上描述的安全密鑰管理協(xié)議而言，這兩個實體可以是發(fā)起者102-1(第一方或A)和響應者102-R(第二方或B)。然而， KMS、會議服務器、LI服務器、功能元件、附加客戶端設(shè)備(各方)和附加服務器可以用相同的架構(gòu)來實現(xiàn)，如圖11的計算設(shè)備所示。因此，出于簡單起見，圖11中沒有示出可以參與本發(fā)明的協(xié)議的所有計算設(shè)備(通信設(shè)備)。如圖所示，標為1102的A的計算設(shè)備和標為1104的B的計算設(shè)備經(jīng)由網(wǎng)絡(luò)1106 耦合。網(wǎng)絡(luò)可以是設(shè)備能夠由此通信的任何網(wǎng)絡(luò)，例如，如在以上所描述的實施例中，網(wǎng)絡(luò)1106可以包括公共可接入的廣域通信網(wǎng)絡(luò)，諸如由網(wǎng)絡(luò)運營商(例如，Verizon、AT&T、 Sprint)運營的蜂窩通信網(wǎng)絡(luò)。然而，本發(fā)明不限于特定類型的網(wǎng)絡(luò)。典型地，設(shè)備可以是客戶機。在此描述的可以由參與協(xié)議的各方采用的客戶端設(shè)備的例子可以包括但不限于 蜂窩電話、智能電話、桌上型電話、個人數(shù)字助理、膝上型計算機、個人計算機等等。然而，一個或多個設(shè)備可以是服務器。因而，應當明白，本發(fā)明的通信協(xié)議不限于計算系統(tǒng)分別是客戶端和服務器的情況，而是可適用于包括兩個網(wǎng)絡(luò)元件的任何計算設(shè)備。如對本領(lǐng)域普通技術(shù)人員來說易于顯見的，服務器和客戶端可以被實現(xiàn)為在計算機程序代碼的控制下操作的編程計算機。計算機程序代碼將被存儲在計算機可讀存儲介質(zhì) (例如，存儲器)中，并且代碼將由計算機的處理器來執(zhí)行。給定本發(fā)明的該公開內(nèi)容，本領(lǐng)域技術(shù)人員可易于產(chǎn)生合適的計算機程序代碼以便實現(xiàn)在此描述的協(xié)議。盡管如此，圖11總體上圖示了用于在網(wǎng)絡(luò)上通信的每個計算機系統(tǒng)的示例性架構(gòu)。如圖所示，設(shè)備1102包括I/O設(shè)備1108-A、處理器1110-A、和存儲器1112-A。設(shè)備1104 包括I/O設(shè)備1108-B、處理器1110-B和存儲器1112-B。應當理解，如在此所使用的，術(shù)語 “處理器”意在包括一個或多個處理設(shè)備，包括中央處理單元(CPU)或其它處理電路，包括但不限于一個或多個信號處理器、一個或多個集成電路等等。而且，如在此所使用的，術(shù)語 “存儲器”意在包括與處理器或CPU相關(guān)聯(lián)的存儲器，諸如RAM、ROM、固定存儲設(shè)備(例如， 硬驅(qū)動器)或可裝卸的存儲設(shè)備(例如，磁盤或CDR0M)。另外，如在此所使用的，術(shù)語“I/ 0設(shè)備”意在包括用于向處理單元輸入數(shù)據(jù)的一個或多個輸入設(shè)備(例如，鍵盤、鼠標)，以及用于提供與處理單元相關(guān)聯(lián)的結(jié)果的一個或多個輸出設(shè)備(例如，CRT顯示器)。因此，在此描述的用于實施本發(fā)明的方法的軟件指令或代碼可以被存儲在一個或多個相關(guān)聯(lián)的存儲設(shè)備中，例如，ROM、固定或可裝卸的存儲器，并且當準備好被利用時，被加載到RAM中并由CPU來執(zhí)行。盡管在此已經(jīng)參考附圖描述了本發(fā)明的說明性實施例，但是應當明白本發(fā)明并不限于這些確切的實施例，并且在不脫離本發(fā)明的范圍或精神的情況下，本領(lǐng)域技術(shù)人員可以做出各種其它改變和修改。
權(quán)利要求
1.一種用于在通信系統(tǒng)中管理在兩方或更多方之間的會議的方法，所述方法包括步驟在所述通信系統(tǒng)的會議管理元件與設(shè)法參與所述會議的所述兩方或更多方中的每一方之間實施基于身份的認證密鑰交換操作，其中，在所述會議管理元件與所述兩方或更多方之間交換的消息是基于所述消息的接收者的相應身份來加密的，并且進一步地，其中所述會議管理元件在所述密鑰認證操作期間從每一方接收基于由該方選擇的隨機數(shù)所計算的隨機密鑰分量；從所述會議管理元件向每一方發(fā)送包括由各方所計算的隨機密鑰分量的集合；在所述會議管理元件處從每一方接收隨機群組密鑰分量，其中，所述隨機群組密鑰分量是由每一方經(jīng)由基于以下內(nèi)容的計算方法來計算的在所述密鑰認證操作期間由該方所使用的隨機數(shù)，以及由設(shè)法參與所述會議的所述兩方或更多方中的其它方的子集所計算的隨機密鑰分量；以及從所述會議管理元件向每一方發(fā)送包括由各方所計算的隨機群組密鑰分量的集合，從而使得每一方能夠計算相同的群組密鑰來在通過所述會議管理元件與每個其它方進行通信時使用。
2.根據(jù)權(quán)利要求1所述的方法，其中，由每一方計算的群組密鑰被表示為 Nai (Ζ』+(N-I)&+(Ν-2)Χ +1+. . . +X"，其中N表示設(shè)法參與所述會議的各方的總數(shù)，ai表示由給定方選擇的隨機數(shù)，Zi表示由所述給定方計算的隨機密鑰分量，Xi表示由所述給定方計算的隨機群組密鑰分量，并且i表示在N方會議中用于所述給定方的會議排序的編號，其中當i = 1時，i-1 = N，并且當i = N時，i+Ι = 1。
3.根據(jù)權(quán)利要求2所述的方法，其中，用于給定方的隨機密鑰分量是通過如下表示的計算方法來計算的％Ρ，其中％是由所述給定方選擇的隨機數(shù)，并且P是選自與基于身份加密的密鑰認證操作相關(guān)聯(lián)的群組的點。
4.根據(jù)權(quán)利要求2所述的方法，其中，用于給定方的隨機群組密鑰分量是通過如下表示的計算方法來計算的 (BitlP-Bi^1P)，其中 是由所述給定方選擇的隨機數(shù)，ai+1P是由在會議排序中就在所述給定方之后的一方發(fā)送到所述會議管理元件的隨機密鑰分量，Bi^1P是由在所述會議排序中就在所述給定方之前的一方發(fā)送到所述會議管理元件的隨機密鑰分量，并且P是選自與密碼密鑰交換協(xié)議相關(guān)聯(lián)的群組的點。
5.根據(jù)權(quán)利要求1所述的方法，其中，設(shè)法參與所述會議的所述兩方或更多方從一個或多個密鑰管理服務獲得相應的私有密鑰。
6.根據(jù)權(quán)利要求1所述的方法，其中，每當以下情況之一時所述群組密鑰就發(fā)生改變 新的一方被添加到所述會議中，以及參與方離開所述會議。
7.根據(jù)權(quán)利要求1所述的方法，其中，功能元件模仿設(shè)法參與所述會議的受污染方，從而使得所述功能元件能夠攔截去往和來自所述受污染方的會議消息。
8.一種用于在通信系統(tǒng)中管理在兩方或更多方之間的會議的裝置，所述裝置包括存儲器；以及耦合到所述存儲器的至少一個處理器，并且所述處理器被配置以便在所述通信系統(tǒng)的會議管理元件與設(shè)法參與所述會議的所述兩方或更多方中的每一方之間實施基于身份的認證密鑰交換操作，其中，在所述會議管理元件與所述兩方或更多方之間交換的消息是基于所述消息的接收者的相應身份來加密的，并且進一步地，其中所述會議管理元件在所述密鑰認證操作期間從每一方接收基于由該方選擇的隨機數(shù)所計算的隨機密鑰分量；從所述會議管理元件向每一方發(fā)送包括由各方所計算的隨機密鑰分量的集合； 在所述會議管理元件處從每一方接收隨機群組密鑰分量，其中，所述隨機群組密鑰分量是由每一方經(jīng)由基于以下內(nèi)容的計算方法來計算的在所述密鑰認證操作期間由該方所使用的隨機數(shù)，以及由設(shè)法參與所述會議的所述兩方或更多方中的其它方的子集所計算的隨機密鑰分量；以及從所述會議管理元件向每一方發(fā)送包括由各方所計算的隨機群組密鑰分量的集合，從而使得每一方能夠計算相同的群組密鑰來在通過所述會議管理元件與每個其它方進行通信時使用，但是其中，所述會議管理元件無法計算所述群組密鑰。
9.一種用于在參與通信系統(tǒng)中的各方之間的會議時使用的方法，在給定方處的所述方法包括步驟在所述通信系統(tǒng)的會議管理元件與所述給定方之間實施基于身份的認證密鑰交換操作，其中，所述會議管理元件還與設(shè)法參與所述會議的其它方實施所述基于身份的認證密鑰交換操作，其中，在所述會議管理元件與所述各方之間交換的消息是基于所述消息的接收者的相應身份來加密的，并且進一步地，其中所述會議管理元件在所述密鑰認證操作期間從每一方接收基于由該方選擇的隨機數(shù)所計算的隨機密鑰分量；在所述給定方處從所述會議管理元件接收包括由各方所計算的隨機密鑰分量的集合；從所述給定方向所述會議管理元件發(fā)送隨機群組密鑰分量，其中所述會議管理元件還從所述其它方中的每一方接收隨機群組密鑰分量，其中，所述隨機群組密鑰分量是由每一方經(jīng)由基于以下內(nèi)容的計算方法來計算的在所述密鑰認證操作期間由該方所使用的隨機數(shù)，以及由設(shè)法參與所述會議的所述各方中的其它方的子集所計算的隨機密鑰分量；在所述給定方處從所述會議管理元件接收包括由各方所計算的隨機群組密鑰分量的集合；以及在所述給定方處計算與由所述其它方計算的群組密鑰相同的群組密鑰，用于在通過所述會議管理元件與每個其它方進行通信時使用。
10.一種用于在參與通信系統(tǒng)中的各方之間的會議時使用的裝置，在給定方處的所述裝置包括存儲器；以及耦合到所述存儲器的至少一個處理器，并且所述處理器被配置以便 在所述通信系統(tǒng)的會議管理元件與所述給定方之間實施基于身份的認證密鑰交換操作，其中，所述會議管理元件還與設(shè)法參與所述會議的其它方實施所述基于身份的認證密鑰交換操作，其中，在所述會議管理元件與所述各方之間交換的消息是基于所述消息的接收者的相應身份來加密的，并且進一步地，其中所述會議管理元件在所述密鑰認證操作期間從每一方接收基于由該方選擇的隨機數(shù)所計算的隨機密鑰分量；在所述給定方處從所述會議管理元件接收包括由所述各方計算的隨機密鑰分量的集合；從所述給定方向所述會議管理元件發(fā)送隨機群組密鑰分量，其中，所述會議管理元件還從所述其它方中的每一方接收隨機群組密鑰分量，其中，所述隨機群組密鑰分量是由每一方經(jīng)由基于以下內(nèi)容的計算方法來計算的在所述密鑰認證操作期間由該方所使用的隨機數(shù)，以及由設(shè)法參與所述會議的所述各方中的其它方的子集所計算的隨機密鑰分量；以及在所述給定方處從所述會議管理元件接收包括由所述各方計算的隨機群組密鑰分量的集合；以及在所述給定方處計算與由所述其它方計算的群組密鑰相同的群組密鑰，用于在通過所述會議管理元件與每個其它方進行通信時使用。
全文摘要
本發(fā)明的原理提供了用于在諸如會議系統(tǒng)的通信環(huán)境中使用的一個或多個安全密鑰管理協(xié)議。例如，一種用于在通信系統(tǒng)中管理兩方或更多方之間的會議的方法包括以下步驟。在所述通信系統(tǒng)的會議管理元件與設(shè)法參與會議的所述兩方或更多方中的每一方之間實施基于身份的認證密鑰交換操作，其中，在所述會議管理元件與所述兩方或更多方之間交換的消息是基于所述消息的接收者的相應身份來加密的，并且進一步地，其中所述會議管理元件在密鑰認證操作期間從每一方接收基于由該方選擇的隨機數(shù)所計算的隨機密鑰分量。所述會議管理元件向每一方發(fā)送包括由各方計算的隨機密鑰分量的集合。所述會議管理元件從每一方接收隨機群組密鑰分量，其中所述隨機群組密鑰分量是由每一方經(jīng)由基于以下內(nèi)容的計算方法來計算的在密鑰認證操作期間由該方所使用的隨機數(shù)，以及由設(shè)法參與會議的所述兩方或更多方中的其它方的子集所計算的隨機密鑰分量。所述會議管理元件向每一方發(fā)送包括由各方計算的隨機群組密鑰分量的集合，從而使得每一方能夠計算相同的群組密鑰來在通過所述會議管理元件與每個其它方進行通信時使用。
文檔編號H04L9/08GK102484582SQ201080038198
公開日2012年5月30日 申請日期2010年8月23日 優(yōu)先權(quán)日2009年8月28日
發(fā)明者G·S·桑達拉姆, V·卡庫萊夫 申請人:阿爾卡特朗訊公司