專利名稱：用于協(xié)商至少一個第一通信用戶和第二通信用戶之間的安全密鑰以保護通信連接的安全 ...的制作方法
技術領域：
本發(fā)明涉及一種用于協(xié)商至少一個第一通信用戶和第二通信用戶 之間的安全密鑰以保護通信連接的安全的方法以及計算機程序產(chǎn)品。
背景技術：
對于第三代移動無線系統(tǒng)來說，由3GPP規(guī)范公開了一種方法， 根據(jù)該方法從用戶和網(wǎng)絡運營商之間的長期安全關系中推導出用戶和 通信網(wǎng)絡設備之間的短期安全關系。該長期的安全關系基于長期保密 的密文密鑰，該密文密鑰存儲在用戶的安全模塊即所謂的UMTS - SIM 卡(技術上更確切的說法在UICC卡上的USIM應用)以及存儲在 網(wǎng)絡運營商的驗證中心。從該長期的密鑰中通過所謂的GBA方法 (GBA = Generic Bootstrapping Architecture,通用自引導架構)推導 出短期的密鑰Ks，其中在終端設備(UE-User Equipment,用戶設 備)、通信網(wǎng)絡中的計算單元(BSF=Bootstrapping Server Function, 自引導服務器功能)以及通信網(wǎng)絡用戶系統(tǒng)(HSS=Home Substriber Server,家庭預定服務器)之間交換消息。為了保護用戶的移動通信終 端i殳備和另 一個通信網(wǎng)絡i殳備(NAF=Network Application Function, 網(wǎng)絡應用功能)之間的通信，在將另一個密鑰推導功能用作Ks一NAF 的條件下采用該短期密鑰。在3G TS 33.220中規(guī)定的GBA方法基于 畫TSAKA協(xié)議(AKA = Authentication and Key Agreement,驗證和 密鑰協(xié)商)。該協(xié)議規(guī)定在3G TS 33.220中，并強制地成為在用戶那 里具有USIM應用的前提。UMTS AKA協(xié)議在此以安全的方式產(chǎn)生分 別具有長度128位的會話密鑰CK和IK。如在TS33.220中規(guī)定的，從 會話密鑰CK和IK中推導出用于保護用戶的移動通信終端設備和通信 網(wǎng)絡設備之間的通信的短期密鑰。
但是按照UMTS標準的移動通信終端設備的推廣還遠不如按照 GSM標準的移動通信終端設備的推廣那樣先進。因此即使是每個GSM
移動無線電話中使用的SIM卡也比仍然很少遇到的UMTS-SIM卡更 為廣泛。但是對于GSM網(wǎng)絡運營商來說很感興趣的是為GSM用戶提 供移動通信終端設備和通信網(wǎng)絡設備之間的安全連接。因此名稱為2G GBA的當前標準化項目的目標是，定義用于保護通信的相應于GBA 的方法，該方法采用SIM卡或者UICC卡上的SIM應用以及GSM協(xié) 議來代替UMTS — SIM卡和UMTS AKA協(xié)議。
緊跟該項目的原因是，期待未來的2G GBA方法不必為了移動通 信終端設備與通信網(wǎng)絡設備的安全通信的目的來建立與用戶之間的新 的長期安全關系。因此應當避免必須向用戶分配新的UMTS-SIM 卡，這總是為網(wǎng)絡運營商帶來很高的成本。因此應當在UICC卡上繼 續(xù)使用用戶那里現(xiàn)有的SIM卡或SIM應用，由此可以利用用戶和網(wǎng)絡 運營商之間業(yè)已存在的關系。
在此的問題是，GSM AKA協(xié)議提供的安全性明顯比UMTS AKA 協(xié)議更低。此外通過GSM AKA協(xié)議產(chǎn)生的會話密鑰對于很多目的來 說顯得太短(最大為64位)。此外該會話密鑰由不安全的算法使用， 例如GSM加密算法A5/1和A5/2。因此存在這些會話密鑰被攻擊者了 解以及由此2G GBA方法的安全性可能完全喪失的危險。
發(fā)明內(nèi)容
因此本發(fā)明要解決的技術問題是，采用GSM AKA協(xié)議和SIM通 過盡可能少的修改來擴大由第三代移動無線系統(tǒng)公知的GBA方法，使 得相對于GSM AKA協(xié)議來說在移動通信終端設備和通信網(wǎng)絡設備通 信時的安全水平得到進一步提高。
本發(fā)明的另一個要解決的技術問題是通過合適的措施改善用于協(xié) 商至少一個第一通信用戶和笫二通信用戶之間的安全密鑰以保護通信 連接的安全的方法，使得該通信的安全水平得以提高，而且經(jīng)過改善 的方法在此疊加在現(xiàn)有的方法上。
根據(jù)本發(fā)明，該技術問題通過具有在權利要求1和20中給出的特 征的方法和計算機程序產(chǎn)品來解決。本發(fā)明的優(yōu)選擴展在從屬權利要 求中給出。
根據(jù)本發(fā)明，在用于協(xié)商至少一個第一通信用戶和第二通信用戶 之間的安全密鑰以保護通信連接的安全的方法中，從驗證和密鑰推導
協(xié)議中確定至少一個第一參數(shù)。此外第二通信用戶以機密方式將附加 參數(shù)傳送給第一通信用戶，使得該傳送的機密性與驗證和密鑰推導協(xié) 議無關地得到保證。最后從第一參數(shù)和附加參數(shù)中確定安全密鑰。
根據(jù)本發(fā)明的實施方式，所述附加參數(shù)是隨機數(shù)，或者是隨機數(shù) 與其它數(shù)據(jù)組成的序列。
根據(jù)本發(fā)明的另一實施方式，包含在附加參數(shù)中的隨機數(shù)是確定 第一參數(shù)的驗證和密鑰推導協(xié)議的組成部分。
根據(jù)本發(fā)明的另一實施方式，第一通信用戶實施為通信終端設 備，第二通信用戶實施為通信網(wǎng)絡設備。
根據(jù)本發(fā)明的優(yōu)選擴展，第二通信用戶相對于第一通信用戶通過 具有公開密鑰的證書得到驗證。
根據(jù)本發(fā)明的優(yōu)選擴展，第一通信用戶相對于第二通信用戶通過 推導出第一參數(shù)的驗證和密鑰推導協(xié)議得到驗證。
根據(jù)本發(fā)明的優(yōu)選擴展，第一通信用戶相對于第二通信用戶借助 專門管理通信網(wǎng)絡的用戶的第三通信用戶得到驗證。
根據(jù)本發(fā)明的優(yōu)選變形，笫一通信用戶實施為按照3GPP移動無 線規(guī)范的用戶設備，第二通信用戶實施為按照3G TS 33.220移動無線 規(guī)范的自引導服務器功能(Bootstrapping Server Function)，第三通 信用戶實施為按照3G TS 33.220移動無線規(guī)范的家庭預定系統(tǒng)。
根據(jù)本發(fā)明的優(yōu)選變形，為了秘密地傳送附加參數(shù)，作為安全協(xié) 議采用按照RFC 2246規(guī)范的傳輸層安全協(xié)議，或者具有按照RFC 3546
規(guī)范的擴展的傳輸層安全協(xié)議。
根據(jù)本發(fā)明的優(yōu)選變形，所述驗證和密鑰推導協(xié)議用于按照3G TS 43.020移動無線規(guī)范確定所述第一參數(shù)。
根據(jù)本發(fā)明的優(yōu)選變形，以合適的方式用按照RFC 3310規(guī)范為 HTTP摘要AKA ( HTTP Digest AKA )(驗證和密鑰協(xié)商)定義的字 段來傳送用于確定第一參數(shù)的所述驗證和密鑰推導協(xié)議的參數(shù)。
根據(jù)本發(fā)明的另一實施方式，按照TS 33.220規(guī)范來進行所述參數(shù) 的傳輸。
根據(jù)本發(fā)明的另一實施方式，以合適的方式用按照RFC3310規(guī)范 為HTTP摘要AKA (驗證和密鑰協(xié)商)定義的字段來傳送所述附加參數(shù)。
根據(jù)本發(fā)明的另一實施方式，所述字段包括"RAND (邊界)"和 "服務器專用數(shù)據(jù)"。
在執(zhí)行本發(fā)明的用于協(xié)商至少一個第一通信用戶和第二通信用戶 之間的安全密鑰以保護通信連接的安全的計算機程序產(chǎn)品時，從驗證 和密鑰推導協(xié)議中確定至少一個第一參數(shù)。此外第二通信用戶以機密 方式將附加參數(shù)傳送給第一通信用戶，使得該傳送的機密性與驗證和 密鑰推導協(xié)議無關地得到保證。當控制程序在程序執(zhí)行控制設備中執(zhí) 行時，從第一參數(shù)和附加參數(shù)中確定安全密鑰。
下面借助附圖詳細解釋實施例。
圖1示出參與自引導方法的實體的示意性網(wǎng)絡模型以及在實體之 間使用的參考點，
圖2示意性示出具有2G驗證向量的自引導方法。
具體實施例方式
在用戶設備(UE) 101和網(wǎng)絡應用功能(NAF) 103之間的通信可 以開始之前，UE和NAF首先必須就是否想要執(zhí)行按照通用自引導架 構(GBA)的過程達成共識。在第一步驟中，UE101開始與NAF103 通過參考點Ua102進行通信而無需任何GBA相關參數(shù)。如果NAF需 要使用通過GBA方法獲得的密鑰，但是通過UE的查詢不包含GBA 相關參數(shù)，則NAF用自引導初始化消息應答。
如果UE101希望與NAF103互動，并且知道將進行自引導過程， 則UE101首先應當進行自引導驗證。但是UE應當僅在已經(jīng)從NAF獲 得了關于必要的自引導初始化的消息或者獲得了要進行自引導重新協(xié) 商的請求之后，或者僅在UE中的密鑰Ks的運行時間結(jié)束之后才進行 自引導驗證。
為此UE201通過參考點Ubl05 (參見圖1)向自引導服務器功能 (BSF) 202發(fā)送HTTPS請求204。該引起初始化的HTTPS請求和 UE與BSF之間的其它所有通信都通過受保護的傳輸層安全(TLS )信 道發(fā)送出去。在建立該TLS信道時，UE通過由BSF提供的證書來驗 證BSF。 UE在此檢查"REALM"屬性是否包含與在BSF提供的證書 中包含的相同的完全合格域名(Fully Qualified Domain Name, FQDN)。
BSF202通過參考點Zh (參見圖1， 104)向家庭預定系統(tǒng)(HSS ) 請求驗證向量和GBA用戶安全設置(GUSS ) 205。 HSS通過Zh參考 點返回GBA用戶安全設置(GUSS )的完整集合以及2G驗證向量(AV -RAND， SRES ， Kc) 205。通過AV類型，BSF知道UE配備了2G SIM。 BSF將3G驗證向量(RAND， Kc ， SRES)轉(zhuǎn)換為偽3G驗證 向量的參數(shù)RANDumts、 RESumts和AUTNUMTS。在此不需要轉(zhuǎn)換為 3G驗證向量的會話密鑰CK和IK:
-RANDUMTS=RAND
-RESUMTS=KDF (密鑰，"3GPP-GBA-RES" ||SRES)，縮減為 128位
—AUTNUMTS=KDF (密鑰，"3GPP-GBA-AUTN" ||RAND )，縮 減為128位，其中密鑰-KcllKcllRAND， KDF是在TS33.220的附件B 中規(guī)定的密鑰推導功能。在此"縮減為128位"意思是，從KDF的256 個輸出位中選擇號碼為1至127的128位。
BSF還必須選擇隨機數(shù)"Ks輸入"，并在HTTP摘要AKA的字 段"aka-nonce ( aka目前)"中設置服務器專用數(shù)據(jù)-Ks輸入。
為了請求UE自我驗證，BSF在"401"消息206中向UE傳遞服 務器專用數(shù)據(jù)(即Ks輸入)RANDumts和AUTN麗Ts。
UE從該消息中提取出RAND并計算對應的Kc和SRES值207。 接著，UE從這些值中計算出偽3G驗證向量參數(shù)RANDumts、 RESUMTS 和AUTNUMTS。 UE將所計算的AUTNumts與BSF所獲得的對應值相比 較。如果這些值不一致，則UE中斷所述過程。
UE向BSF208發(fā)送具有摘要AKA應答的另一個HTTP請求，其
中將RESuMTS用作密碼。
BSF通過驗證摘要AKA應答209來驗證UE。如果該驗證是錯誤 的，則BSF不應當在后續(xù)通信中繼續(xù)使用該驗證向量。
BSF通過計算Ks二KDF(密鑰IIKs輸入，"3GPP-GBA-Ks，， ||SRES) 來產(chǎn)生密鑰材料Ks210。自引導事務標識符(B-TID)值應當用NAI 格式通過引入對基站64編碼的RANDumts值以及BSF服務器名產(chǎn)生， 如Base64encode(RANDuMTS)@BSF—Servers—Domain—Name 。
BSF將200 OK消息連同B-TID —起發(fā)送給UE211 ，以確i人驗證 已進行。此外，BSF還在200 0K消息中傳送密鑰Ks的運行時間。 UE按照與BSF212相同的方式產(chǎn)生密鑰材料Ks。 UE和BSF都將密鑰材料Ks用于推導密鑰材料Ks—NAF，以保護 參考點Ua。 Ks_NAF通過Ks_NAF=KDF(Ks ，密鑰推導參數(shù))來計算， 其中KDF是在附件B中規(guī)定的密鑰推導功能，而且密鑰推導參數(shù)由用 戶IMPI、 NAFID和RAND_UMTS組成。NAF—ID由NAF的全DNS 名組成。為了保證在UE和BSF中基于NAF名進行一致的密鑰推導， 應當滿足下面三個前提條件中的至少一個
1. NAF在DNS中僅以一個域名(FQDN)公知，因此不應當有兩 個不同的域名指向NAF的IP地址。這通過管理措施來實現(xiàn)。
2. NAF的每個DNS項都指向不同的IP地址。NAF對所有這些 IP地址進行應答。每個IP地址通過NAF配置與對應的FQDN關聯(lián)。 NAF可以借助該IP地址識別出應當將哪個FQDN用于密鑰推導。
3. 參考點Ua使用將主機名一起傳送給NAF的協(xié)議。這迫使NAF 檢查該主機名的有效性，以便在與UE的所有通信中都使用該名稱，如 果設置了 UE的話，并且將該名稱傳送給BSF，以保證密鑰材料Ks—NAF 的正確推導。
UE和BSF應當將密鑰Ks連同所屬的B-TID—起存儲，直到密鑰 Ks的運行時間結(jié)束為止或者直到更新密鑰Ks為止。
如果密鑰Ks—NA是為對應的密鑰推導參數(shù)NAF_ID存在的，則 UE和NAF可以通過參考點Ua開始安全的通信。
目前對這樣的2G GBA方法公知有兩種解決方案，它們在相關標 準化組3GPP SA3的Nokia文獻S3-050053和Qualcomm文獻S3-050097 中介紹。
Nokia文獻S3-050053解決了短期GSM會話密鑰Kc的問題，其中 該文獻對2G GBA方法的一個實例使用GSM AKA協(xié)議的多個實例， 即所謂的GSM三元組(GSM Triplets )。由此獲得多個會話密鑰Kc， 然后將這些會話密鑰組合成足夠長的短期密鑰。GSM AKA協(xié)議在此用 于用戶相對于網(wǎng)絡的驗證、網(wǎng)絡相對于用戶的驗證以及用于協(xié)商會話 密鑰。作為GSM AKA協(xié)議的載體協(xié)議，采用按照RFC3310規(guī)范的 HTTP摘要AKA協(xié)議，其中通過轉(zhuǎn)換功能適當匹配GSM AKA協(xié)議的
參數(shù)。
Qualcomm文獻S3-050097采用Diffie Hellman方法來用于會話密 鑰的協(xié)商。網(wǎng)絡相對于用戶的驗證基于通過Diffie Hellman方法的參數(shù) 來使用證書和數(shù)字簽名。GSM AKA協(xié)議只用于用戶相對于網(wǎng)絡的驗 證，其中GSM密鑰Kc用于通過Diffie Hellman方法的參數(shù)來形成消 息驗證代碼(MAC)。
相應地，本發(fā)明根據(jù)該實施例按照以下方式來解決上述問題
本發(fā)明的方法采用按照規(guī)范RFC3310的HTTP摘要AKA協(xié)議作 為GSM AKA協(xié)議的載體協(xié)議，其中GSM AKA協(xié)議的參數(shù)通過合適 的轉(zhuǎn)換功能得到匹配。在此每個2G GBA實例只使用GSM AKA協(xié)議 的一個實例。此外，在移動通信終端設備和BSF之間建立按照RFC2246 規(guī)范的傳輸層安全連接(TLS)。在該TLS連接中啟動強大的加密。 BSF相對于移動通信終端設備的驗證在建立TLS連接時基于證書地進 行。但是移動通信終端設備在建立TLS連接時沒有經(jīng)過驗證。移動通 信終端設備相對于BSF的驗證是通過采用嵌入HTTP摘要AKA協(xié)議 中的GSM AKA來進行的。
由此給出以下有利效果短期密鑰的安全性根據(jù)本發(fā)明的方法既 基于GSM的安全性又基于TLS的安全性。僅當兩個方法GSM和TLS 都在具體的使用環(huán)境中崩潰，或者可以對GSM進行難以進行的攻擊， 使得GSM方法在這里描述的自引導方法運行期間崩潰時，該安全性才 會喪失。
在通過密鑰推導功能計算短期密鑰時使用從GSM協(xié)議獲得的參 數(shù)Kc和SRES (簽名響應)和隨機數(shù)，它們通過TLS加密保護地作為 HTTP摘要AKA協(xié)議的一部分從BSF秘密地傳送給移動通信設備。這 些隨機數(shù)例如可以在按照RFC3310規(guī)范的字段"AKA-NONCE"中， 既作為Challenge RAND也作為"服務器專用數(shù)據(jù)"的一部分傳輸。 通過本發(fā)明方法所提出的措施，尤其是給出以下優(yōu)點 -為了找到所推導出的短期密鑰，攻擊者必須既找到GSM參數(shù) Kc和SRES，又找到秘密地通過TLS傳輸?shù)碾S機數(shù)，也就是說攻擊者 必須既攻擊GSM方法又攻擊TLS方法的使用。由此明顯提高了抵制 攻擊的安全性。
-相對于在S3-050053中的建議，所推導出的短期密鑰的有效長度
通過采用隨機數(shù)Ks輸入作為附加參數(shù)的一部分而得到了顯著提高，該 附加參數(shù)不是GSM AKA的組成部分。由此再次提高了抵制攻擊的安全性。
-每個2G GBA實例只需要采用唯一的一個GSM AKA實例。與 S3-050053中的建議相比，這導致GSM驗證中心上的負荷明顯降低。
-對于S3-050053中的建議的安全性，通常需要可靠地防止攻擊者 每次重新在另一個明文中使用在2GGBA中采用的GSM三元組。本來 由此例如可以通過攻擊加密算法A5/1或A5/2確定參數(shù)Kc和SRES， 并由此確定2GGBA的短期密鑰。但是這在實踐中是非常難以實現(xiàn)的。 相反，對在此所述的方法的攻擊僅在攻擊者在2G GBA的協(xié)議運行過 程中能確定GSM參數(shù)Kc和SRES時才可以。但是根據(jù)目前的知識水 平這在幾秒的時間內(nèi)僅對算法A5/2才可以，但是該算法不再被允許用 于支持2GGBA的終端設備。因此所提出的方法不僅明顯比S3-050053 中的建議更實用，而且還提高了安全性。
-相對于S3-050097中的建議的另一個優(yōu)點是本發(fā)明的安全性基 于多個獨立的因素。尤其是UE還可以通過比較所計算的和所接收的 AUTNuMTs來驗證BSF。相反，Qualcomm建議的安全性只是基于借助 證書對BSF的安全驗證。
文獻
3G S3-050053參見
ftp:〃ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_37—Sophia/Docs/ 3G S3-050097參見
ftp:〃ftp.3gpp.org/TSG一SA/WG3一Security/TSGS3—37一Sophia/Docs/
3G TS 33.220 v6.4.0參見fttp:〃ftp.3gpp.org/Specs/
3G TS 33.102 v6.3.0參見fttp:〃ftp.3gpp.org/Specs/
3G TS 43.020 v6丄0參見fttp:〃ftp.3gpp.org/Specs/
RFC 3310參見http:〃www.ietf.org/rfc.html
RFC 2246參見http:〃www.ietf.org/rfc.html
權利要求
1.一種用于協(xié)商至少一個第一通信用戶和第二通信用戶之間的安全密鑰以保護通信連接的安全的方法，其中從驗證和密鑰推導協(xié)議中確定至少一個第一參數(shù)，第二通信用戶以機密方式將附加參數(shù)傳送給第一通信用戶，使得該傳送的機密性與驗證和密鑰推導協(xié)議無關地得到保證，從第一參數(shù)和附加參數(shù)中確定安全密鑰。
2. 根據(jù)權利要求l所述的方法，其中所述附加參數(shù)可以分為至少 一個第一部分和第二部分。
3. 根據(jù)上述權利要求之一所述的方法，其中所述附加參數(shù)是隨機 數(shù)，或者是隨機數(shù)與其它數(shù)據(jù)組成的序列。
4. 根據(jù)上述權利要求之一所述的方法，其中所述隨機數(shù)的一部分 是確定第一參數(shù)的驗證和密鑰推導協(xié)議的組成部分。
5. 根據(jù)上述權利要求之一所述的方法，其中第一通信用戶實施為 通信終端設備，第二通信用戶實施為通信網(wǎng)絡設備。
6. 根據(jù)上述權利要求之一所述的方法，其中第二通信用戶相對于 第一通信用戶通過具有公開密鑰的證書得到驗證。
7. 根據(jù)上述權利要求之一所述的方法，其中第一通信用戶相對于 第二通信用戶通過推導出第一參數(shù)的驗證和密鑰推導協(xié)議得到驗證。
8. 根據(jù)上述權利要求之一所述的方法，其中第一通信用戶相對于 第二通信用戶借助專門管理通信網(wǎng)絡的用戶的第三通信用戶得到驗證。
9. 根據(jù)上述權利要求之一所述的方法，其中第一通信用戶實施為 按照3GPP移動無線規(guī)范的用戶設備(UE)，第二通信用戶實施為按 照3G TS 33.220移動無線規(guī)范的自引導服務器功能(BSF)，第三通 信用戶實施為按照3G TS 33.220移動無線規(guī)范的家庭預定系統(tǒng)(HSS)。
10. 根據(jù)上述權利要求之一所述的方法，其中為了秘密地傳送附 加參數(shù)，作為安全協(xié)議采用按照RFC 2246規(guī)范的傳輸層安全協(xié)議(TLS)，或者具有按照RFC 3546規(guī)范的擴展的傳輸層安全協(xié)議。
11. 根據(jù)上述權利要求之一所述的方法，其中所述驗證和密鑰推導協(xié)議用于按照3G TS 43.020移動無線規(guī)范來確定所述笫一參數(shù)。
12. 根據(jù)上述權利要求之一所述的方法，其中以合適的方式，用 按照RFC 3310規(guī)范為HTTP摘要AKA (驗證和密鑰協(xié)商)定義的字 段來傳送用于確定第一參數(shù)的所述驗證和密鑰推導協(xié)議的參數(shù)。
13. 根據(jù)權利要求11所述的方法，其中按照TS 33.220規(guī)范來進 行所述參數(shù)的傳輸。
14. 根據(jù)上述權利要求之一所述的方法，其中以合適的方式用按 照RFC3310規(guī)范為HTTP摘要AKA (驗證和密鑰協(xié)商)定義的字段 來傳送所述附加參數(shù)。
15. 根據(jù)權利要求13所述的方法，其中所述附加參數(shù)的至少兩個 部分用不同的字段來傳輸。
16. 根據(jù)上述權利要求之一所述的方法，其中所述字段包括 "RAND"和"服務器專用數(shù)據(jù)"。
17. 根據(jù)上述權利要求之一所述的方法，其中。所述密鑰推導功 能實施為具有輸入?yún)?shù)Hashkey和Hashdata的密鑰推導功能。
18. 根據(jù)權利要求16所述的方法，其中所述附加參數(shù)的第一部分 在Hashkey中，所述附加參數(shù)的第二部分在Hashdata中。
19. 根據(jù)權利要求16所述的方法，其中所述附加參數(shù)的第一部分 在Hashkey和Hashdata中，所述附加參數(shù)的第二部分在Hashkey中。
20. —種可加載到程序運行控制裝置的工作存儲器中并具有至少 一個代碼段的計算機程序產(chǎn)品，在其執(zhí)行時用于協(xié)商至少一個第一通 信用戶和第二通信用戶之間的安全密鑰以保護通信連接的安全的計算 機程序產(chǎn)品，從驗證和密鑰推導協(xié)議中確定至少一個笫一參數(shù)， 第二通信用戶以秘密的方式將附加參數(shù)傳送給笫一通信用戶，使得該傳送的機密性與驗證和密鑰推導協(xié)議無關地得到保證，當控制程序在程序執(zhí)行控制設備中執(zhí)行時，從第一參數(shù)和附加參 數(shù)中確定安全密鑰。
全文摘要
一種用于協(xié)商至少一個第一通信用戶和第二通信用戶之間的安全密鑰以保護通信連接的安全的方法。本發(fā)明的任務在于通過合適的措施改善用于協(xié)商至少一個第一通信用戶和第二通信用戶之間的安全密鑰以保護通信連接的安全的方法，使得該通信的安全水平得以提高，而且經(jīng)過改善的方法在此疊加在現(xiàn)有的方法上。為了解決該任務，根據(jù)本發(fā)明在用于協(xié)商至少一個第一通信用戶和第二通信用戶之間的安全密鑰以保護通信連接的安全的方法中，從驗證和密鑰推導協(xié)議中確定至少一個第一參數(shù)。此外第二通信用戶以機密方式將附加參數(shù)傳送給第一通信用戶，使得該傳送的機密性與驗證和密鑰推導協(xié)議無關地得到保證。最后從第一參數(shù)和附加參數(shù)中確定安全密鑰。
文檔編號H04W12/06GK101194529SQ200680020548
公開日2008年6月4日 申請日期2006年4月10日 優(yōu)先權日2005年6月10日
發(fā)明者G·霍恩, M·布洛馬爾特 申請人:西門子公司