專利名稱：用于安全且?guī)捀咝У拿艽a同步的方法
技術(shù)領(lǐng)域：
本發(fā)明大體上涉及通信領(lǐng)域，尤其是安全通信領(lǐng)域。
技術(shù)背景安全或密碼協(xié)議是執(zhí)行與安全性有關(guān)的功能和應(yīng)用密碼方法的抽 象或具體的協(xié)議。密碼協(xié)議被廣泛用于安全應(yīng)用層數(shù)據(jù)傳輸。密碼協(xié)議 通常合并以下方面中的至少一些密鑰協(xié)商或建立；實(shí)體鑒別 (authentication);對(duì)稱加密和消息鑒別材料構(gòu)建；安全應(yīng)用層數(shù)據(jù) 傳輸；和不可拒絕方法。在不可靠的傳輸機(jī)制上運(yùn)行的密碼協(xié)議需要用于例如由于分組丟 失或分組重定序的緣故而同步發(fā)送器和接收器的手段。在最低層，接收 器必須能夠正確地將數(shù)據(jù)分組組裝成"可理解的，，數(shù)據(jù)；例如，它必須 知道數(shù)據(jù)分組是否丟失以使它能夠請(qǐng)求重傳。同步常常是通過(guò)添加序號(hào) (sequence number )到每個(gè)分組或通過(guò)使用已經(jīng)存在的序號(hào)來(lái)完成的。 這樣的序號(hào)然后與適當(dāng)?shù)拿荑€一起被輸入到密碼算法，并且同步是在每 個(gè)分組的基礎(chǔ)上獲得的。然而，后一種方法是優(yōu)選的，這是因?yàn)樗鼪](méi)有 增加數(shù)據(jù)量，因此也沒(méi)有增加必要的帶寬。由于密碼變換的特性的緣故，使得相同的序號(hào)絕不應(yīng)該;故和相同的 密鑰一起使用兩次。然而，常規(guī)的嵌入式計(jì)數(shù)器常常只有16位，因此 在高速通信中，16位的序號(hào)空間可能在大概秒的量級(jí)內(nèi)就"繞回(wrap)" 了，從而由于必需的頻繁的重新加密而導(dǎo)致低效率。例如，在使用16 位的序號(hào)的情況下，每2"個(gè)分組就將包含相同的序號(hào)，因此接收器無(wú) 法區(qū)別這樣的分組。為了避免該問(wèn)題，翻轉(zhuǎn)(rol卜over)計(jì)數(shù)器("ROC")能夠被用 于限定"擴(kuò)展的"序號(hào)。對(duì)于16位的序號(hào)(sequence—number)，擴(kuò)展 的序號(hào)(EXTENDED-SEQ )可以等于sequence—number + R0O2"。在這樣 的系統(tǒng)中，每當(dāng)sequence—number "繞回"才莫2"， ROC都應(yīng)該在發(fā)送器和接收器端被更新。然而，ROC值常常不在分組中攜帶，而是被發(fā)送器 和接收器隱含地保持。然而，能夠表現(xiàn)出的是，只要分組重定序/丟失 不超過(guò)2",就可以通過(guò)根據(jù)探試法估計(jì)ROC值來(lái)保持同步；參見(jiàn)例如因 特網(wǎng)工程任務(wù)組(IETF)請(qǐng)求注解(RFC) 3711的附錄，"安全實(shí)時(shí)傳 輸協(xié)議，，("SRTP")。
然而，在其中用戶可以加入或離開(kāi)進(jìn)行中的會(huì)話的一些應(yīng)用中(例 如3GPP多播和廣播服務(wù)(MBMS)，此處將要使用SRTP),由于每個(gè)用 戶必須被給予當(dāng)前ROC值并且如何準(zhǔn)確地將該信息傳送到用戶也不是小 事這樣事實(shí)，使得該"擴(kuò)展"的機(jī)制是不夠充分的。SRTP當(dāng)前不提供用 于使用帶內(nèi)信令傳輸提供ROC值的機(jī)制。然而，可以使用密鑰管理協(xié)議 (例如多媒體因特網(wǎng)密鑰("MIKEY，， ) , IETF RFC3830 )來(lái)通過(guò)帶外 發(fā)信號(hào)通知所述值。這種方法的問(wèn)題是密鑰管理常常是通過(guò)獨(dú)立的過(guò)程 來(lái)執(zhí)行的，并且在用戶決定加入會(huì)話之前很久就執(zhí)行密鑰管理也不是不 可能。在這種情況下，在密鑰管理被執(zhí)行過(guò)時(shí)所使用過(guò)的R0C的值將在 用戶加入會(huì)話時(shí)就不會(huì)有效。
即使密鑰管理是與SRTP流處理或多或少地同步執(zhí)行的，但是由于 SRTP對(duì)擴(kuò)展的序號(hào)進(jìn)行估計(jì)的方式的緣故造成R0C值將會(huì)不正確也是 可能的。例如，假定媒體(SRTP)序號(hào)已經(jīng)剛剛繞回(例如等于0x0000 ) 并且密鑰管理在該時(shí)間點(diǎn)讀取ROC值。接著，ROC值被傳輸?shù)接脩?接 收器)，并且用戶讀取ROC值并且將其存儲(chǔ)以供參考。因?yàn)榉纸M在媒體 服務(wù)器和用戶之間的路徑上可能會(huì)被重定序，所以用戶所接收的第 一媒 體(SRTP)分組可能是延遲的分組，該延遲的分組碰巧具有例如等于 0xFFFF的序號(hào)。在這種情況下，SRTP可能處理該(延遲的)分組，該 分組具有的ROC值也高出1。而且，所接收的下一SRTP分組很可能具有 等于0x0000的序號(hào)。在這種情況下，SRTP將會(huì)猜測(cè)或估計(jì)序號(hào)已經(jīng)繞 回并且，因此將使它的ROC值增1。這將會(huì)導(dǎo)致同步的失敗。在嚴(yán)重的 分組丟失的條件下，或者如果用戶離開(kāi)會(huì)話并且在ROC已經(jīng)繞回至少一 次這樣長(zhǎng)的時(shí)間段之后重新加入，該問(wèn)題會(huì)重新出現(xiàn)。
因此，在本領(lǐng)域中需要用于安全且?guī)捀咝У拿艽a同步的方法。優(yōu) 選地，這樣的方法應(yīng)該有效利用帶寬并且防止未經(jīng)授權(quán)的操縱。

發(fā)明內(nèi)容
為了克服現(xiàn)有技術(shù)的缺陷，本發(fā)明公開(kāi)了用于安全且?guī)捀咝У拿艽a同步的方法。通常，當(dāng)分組序號(hào)的函數(shù)等于預(yù)定值時(shí)，翻轉(zhuǎn)計(jì)數(shù)器
U0C)值被周期性地追加于數(shù)據(jù)分組并且與數(shù)據(jù)分組一起被傳送。ROC 有效地同步數(shù)據(jù)分組的密碼變換。
根據(jù)將在下文中更加充分描述的示例性實(shí)施例，在發(fā)送器接收數(shù)據(jù) 分組以供傳輸?shù)浇邮掌鳎凰龇椒ㄓ绕溥m用于其中數(shù)據(jù)分組是使用在因 特網(wǎng)工程任務(wù)組(IETF)請(qǐng)求注解(RFC) 3711中定義的安全實(shí)時(shí)傳輸 協(xié)議(SRTP)而被傳送的系統(tǒng)中，在此將其并入作為參考。發(fā)送器首先 確定用于數(shù)據(jù)分組的分組序號(hào)是否能夠被R整除，此處R是發(fā)送器和接 收器事先約定的整數(shù)。發(fā)送器和接收器能夠例如進(jìn)行帶外通信以選擇R 的值；用于這種用途的適當(dāng)協(xié)議包括會(huì)話發(fā)起協(xié)議(SIP)、安全實(shí) 時(shí)傳輸(RTSP)和多媒體因特網(wǎng)密鑰(MIKEY)。
如杲分組序號(hào)能夠被R整除，則發(fā)送器計(jì)算代碼并且將其追加于數(shù) 據(jù)分組，其中所述代碼是與所述數(shù)據(jù)分組相關(guān)聯(lián)的鑒別密鑰和發(fā)送器翻 轉(zhuǎn)計(jì)數(shù)器(ROC)值的函數(shù)。發(fā)送器ROC值與發(fā)送器中的計(jì)數(shù)器相對(duì)應(yīng)， 每當(dāng)所述發(fā)送器中的序號(hào)計(jì)數(shù)器翻轉(zhuǎn)，該計(jì)數(shù)器都遞增。發(fā)送器還將發(fā) 送器ROC值追加于所述數(shù)據(jù)分組，并且所述數(shù)據(jù)分組然后被傳送到接收 器。然而，如果分組序號(hào)不能被R整除，則發(fā)送器僅僅傳送沒(méi)有追加發(fā) 送器ROC值的數(shù)據(jù)分組。
當(dāng)接收到時(shí)，接收器確定發(fā)送器ROC值是否被追加于所迷數(shù)據(jù)分組， 其中如果分組序號(hào)能被R整除，則就表明發(fā)送器ROC值的存在。如果數(shù) 據(jù)分組不包括發(fā)送器ROC值，則接收器使用依賴于接收器本地保持的 ROC值而估計(jì)的ROC值來(lái)執(zhí)行分組安全性處理。如果所述數(shù)據(jù)分組確實(shí) 包括發(fā)送器ROC值，則發(fā)送器使用發(fā)送器ROC值而不是接收器ROC值(或 ROC值的估計(jì))來(lái)執(zhí)行分組安全性處理。作為該安全性處理的一部分， 數(shù)據(jù)分組的完整性(integrity)被確定。如果數(shù)據(jù)分組的完整性沒(méi)有 被確認(rèn)，則所述數(shù)據(jù)分組被丟棄并且不進(jìn)行進(jìn)一步處理。否則，如果數(shù) 據(jù)分組的完整性被確認(rèn)，則接收器ROC值被設(shè)置為發(fā)送器ROC值。
上文已經(jīng)相當(dāng)寬泛地概述了本發(fā)明的原理以使本領(lǐng)域技術(shù)人員可 以更好地理解隨后的示例性實(shí)施例的詳細(xì)描述。本領(lǐng)域技術(shù)人員應(yīng)該理 解的是，他們能夠很容易地將所公開(kāi)的構(gòu)思和示例性實(shí)施例用作設(shè)計(jì)或 修改用于實(shí)現(xiàn)本發(fā)明的相同目的的其他結(jié)構(gòu)或方法的基礎(chǔ)。本領(lǐng)域技術(shù) 人員還應(yīng)該認(rèn)識(shí)到這樣的等同構(gòu)造不會(huì)偏離如下文提供的權(quán)利要求所定義的本發(fā)明的最廣泛的精神和范圍。


為了說(shuō)明本發(fā)明的特征和功能，現(xiàn)在參照結(jié)合附圖所給出的如下詳
細(xì)描述，在所述附圖中
圖1其中圖示了根據(jù)本發(fā)明原理的用于安全且?guī)捀咝У拿艽a同步 的系統(tǒng)和方法。
具體實(shí)施例方式
圖1其中圖示了根據(jù)本發(fā)明原理的用于安全且?guī)捀咝У拿艽a同步 的系統(tǒng)和方法。所述系統(tǒng)包括發(fā)送器101和接收器102，每個(gè)都根據(jù)下 文所描述的原理可操作地執(zhí)行某些操作。在此關(guān)于示例性系統(tǒng)來(lái)明確地 描述用于密碼同步的方法，在所述示例性系統(tǒng)中，數(shù)據(jù)分組是使用在因 特網(wǎng)工程任務(wù)組(IETF)請(qǐng)求注解(RFC) 3711中定義的安全實(shí)時(shí)傳輸 協(xié)議(SRTP)而被傳送的。然而，本領(lǐng)域技術(shù)人員將會(huì)認(rèn)識(shí)到該方法對(duì) 基于其他傳輸協(xié)議的系統(tǒng)的普遍適用性以及對(duì)這樣的其他協(xié)議(如果有 的話)所需的適應(yīng)性。
為了在基于SRTP的系統(tǒng)中實(shí)施本發(fā)明的原理，消息鑒別算法，在 此被稱作擴(kuò)展的消息鑒別碼(XMAC)，能夠被添加到SRTP框架。XMAC 能夠例如于基于因特網(wǎng)工程任務(wù)組(IETF)基于哈希(hash)的消息鑒 別碼(HMAC)或任何其他安全MAC。從SRTP框架的角度看，本領(lǐng)域技術(shù) 人員根據(jù)如下描述將會(huì)認(rèn)識(shí)到XMAC與其他MAC算法的工作基本上類 似。然而，除了鑒別密鑰之外，XMAC包括參數(shù)R,其是0-2"范圍內(nèi)的整 數(shù)。發(fā)送器101和接收器102能夠使用例如本領(lǐng)域中已知的帶外信令傳 輸來(lái)約定MAC和R的值；用于這種用途的適當(dāng)協(xié)議包括會(huì)話發(fā)起協(xié)議 (SIP)、安全實(shí)時(shí)傳輸(RTSP)和多媒體因特網(wǎng)密鑰(MIKEY)。
根據(jù)本方法，在發(fā)送器101接收到數(shù)據(jù)分組以傳輸?shù)浇邮掌?Q2(步 驟1G3)。接著(步驟104),對(duì)該數(shù)據(jù)分組執(zhí)行SRTP處理，除完整性 變換(integrity transform )之外。該步驟涉及導(dǎo)出要被用于數(shù)據(jù)保 護(hù)(即加密和完整性保護(hù))的密鑰以及處理數(shù)據(jù)分組直到完整性保護(hù)將 被應(yīng)用的點(diǎn)(例如，任何可能的SRTP加密都應(yīng)該在該步驟期間執(zhí)行)。
隨后的步驟構(gòu)成對(duì)數(shù)據(jù)分組(包括首部和有效載荷)的XMAC完整 性保護(hù)。首先(步驟105),確定該數(shù)據(jù)分組的序號(hào)(sequence—number) (所述序號(hào)能夠在分組首部中獲得)是否能夠被R整除(即0模R)。如果分組序號(hào)不能被R整除，則不對(duì)該數(shù)據(jù)分組添加MAC標(biāo)簽，并且數(shù) 據(jù)分組的處理繼續(xù)進(jìn)行到步驟108,其中在傳輸(109)之前，完成對(duì)數(shù) 據(jù)分組的SRTP處理。如果分組序號(hào)能夠被R整除，則就要為數(shù)據(jù)分組 計(jì)算MAC標(biāo)簽。在步驟106中，MAC標(biāo)簽被計(jì)算并且被添加到數(shù)據(jù)分組。MAC是與數(shù) 據(jù)分組相關(guān)聯(lián)的SRTP鑒別密鑰和發(fā)送器翻轉(zhuǎn)(roll-over )計(jì)數(shù)器(R0C) 值的函數(shù)，用公示表示為HMAC (密鑰，RTP — packet分組1IR0C)。發(fā)送 器ROC值與發(fā)送器中的計(jì)數(shù)器相對(duì)應(yīng)，每當(dāng)發(fā)送器中的序號(hào)計(jì)數(shù)器翻轉(zhuǎn)， 所迷計(jì)數(shù)器都遞增。接著(步驟107)，發(fā)送器ROC值也被追加于數(shù)據(jù) 分組；即，數(shù)據(jù)分組現(xiàn)在已經(jīng)被附加了 HAMC (密鑰，RTP-packet分組 IIROC) IIROC。步驟106和107的作用是將發(fā)送器ROC值，由MAC值保 護(hù)的完整性添加到每一第R個(gè)分組。對(duì)MAC的輸入(即，RTP—packet分 組| IROC)將由SRTP框架按照這種方式自動(dòng)地(根據(jù)RFC3711 )格式化， 并且被作為輸入來(lái)提供。本領(lǐng)域技術(shù)人員應(yīng)該注意到發(fā)送器ROC值將 不是作為分組有效載荷的一部分而是作為MAC標(biāo)簽的一部分傳送的；即 HMAC (密鑰，RTP—packet分組l |ROC) I |R0C能夠被視為XMAC的輸出鑒 別標(biāo)簽。最終，如同對(duì)具有不能被R整除的序號(hào)的數(shù)據(jù)分組一樣，對(duì)數(shù)據(jù)分 組的處理繼續(xù)到步驟108，其中在傳輸(步驟109)到接收器102之前 完成對(duì)數(shù)據(jù)分組的SRTP處理。本領(lǐng)域技術(shù)人員應(yīng)該認(rèn)識(shí)到，雖然在接 收器102中執(zhí)行的過(guò)程開(kāi)始于步驟110，但是發(fā)送器101和接收器102 的操作是異步的。當(dāng)接收到數(shù)據(jù)分組時(shí)(步驟110 ) , SRTP處理就被執(zhí)行， 一直到(但 不包括)SRTP密鑰導(dǎo)出的步驟為止。接著(步驟U2),確定發(fā)送器翻 轉(zhuǎn)計(jì)數(shù)器(ROC )值是否被追加于所述數(shù)據(jù)分組。如果分組序號(hào)能夠被R 整除(即，sequence—number = 0才莫R ),就表明追加于數(shù)據(jù)分組的發(fā) 送器ROC值以及XMAC的存在。如果沒(méi)有ROC/XMAC被追加于數(shù)據(jù)分組，則處理繼續(xù)到步驟121,其 中使用常規(guī)ROC估計(jì)來(lái)執(zhí)行標(biāo)準(zhǔn)SRTP密鑰導(dǎo)出。在這種情況下，接收 器102考慮其本地存儲(chǔ)的ROC值(ROC_L)，典型地該值是與先前分組 相關(guān)聯(lián)的ROC值。接收器然后檢查剛接收到的數(shù)據(jù)分組中的序號(hào)(SEQ) 和先前接收到的最高序號(hào)(S_L),其也被接收器跟蹤。使用那三個(gè)值(R0L-L、 SEQ和S-L)，接收器能夠估計(jì)在數(shù)椐分組被傳送時(shí)發(fā)送器了 使用什么R0C值。這能夠以若干種方式完成，例如在IETF RFC 3711的 附錄中描述的，在其中被稱作"索引估計(jì)(index estimation)"。作 為例子，如果當(dāng)前ROC-L值是"x，， ， S_L是三(0x0003 )而所接收的 SEQ是Oxffff，則接收器將猜測(cè)當(dāng)前數(shù)據(jù)分組是延遲的分組(延遲了,四 個(gè)時(shí)間"單位")，對(duì)應(yīng)于R0C = R0C_L-1 (即，x-1),這是由于SEQ 的"繞回(wrap)"出現(xiàn)在兩個(gè)分組的接收之間。(本領(lǐng)域技術(shù)人員將 會(huì)認(rèn)識(shí)到在SEQ = Oxffff之后，下一 SEQ將會(huì)繞回并且下一分組具有SEQ
=0x0000等)。當(dāng)然還會(huì)出現(xiàn)這樣的情況分組確實(shí)與相同的ROC-L值 相對(duì)應(yīng)，并且事實(shí)上，2"-3個(gè)連續(xù)的分組已經(jīng)丟失。然而，該情形的 可能性4艮小，所以能夠認(rèn)為接收器使用"最大似然"估計(jì)技術(shù)；即， 它在假定最小穩(wěn)定量的丟失/重排序/延遲已經(jīng)發(fā)生的情況下選擇可能 性最大的R0C。
如果數(shù)據(jù)分組確實(shí)包括發(fā)送器ROC值(步驟112),則使用發(fā)送器 ROC值而不是接收器ROC值來(lái)執(zhí)行SRTP密鑰導(dǎo)出(步驟113 )。接著(步 驟114)，數(shù)據(jù)分組的完整性被確定。這能夠通過(guò)使用所導(dǎo)出的密鑰檢 查追加于分組的XMAC以驗(yàn)證數(shù)據(jù)尚未被破壞或篡改(尤其是發(fā)送器ROC 是正確的的情況下)來(lái)完成。例如，設(shè)"MAC—INPUT"是由SRTP提供作 為對(duì)XMAC的數(shù)據(jù)輸入的數(shù)據(jù)值(即，在RFC3711中定義的SRTP分組的 經(jīng)鑒別的部分)，并且設(shè)t'為所接收的標(biāo)簽，也被SRTP提供作為輸入。 接著，計(jì)算t-HMAC(密鑰，MAC-INPUTlir {4})并且將其與包含在分組 中的值[4]進(jìn)行比較，其中X[n]表示與幾乎X的n個(gè)最右邊的所有字 節(jié)相對(duì)應(yīng)的子串，而X(n)表示X的n個(gè)最右邊的字節(jié)。當(dāng)且僅當(dāng)值t和 [4]相等時(shí)，XMAC才通過(guò)驗(yàn)證。
如果數(shù)據(jù)分組的完整性沒(méi)有被確認(rèn)(步驟115),則該數(shù)據(jù)分組被 丟棄(步驟116)。否則，如杲數(shù)據(jù)分組的完整性被確認(rèn)(步驟115), 則接收器ROC值被設(shè)置為包含在數(shù)據(jù)分組中的發(fā)送器ROC值(步驟117 )， 從而使發(fā)送器101和接收器102的R0C值同步。接著，在步驟118中， 發(fā)送器ROC值和XMAC被從數(shù)據(jù)分組中移除，繼之以完成對(duì)數(shù)據(jù)分組的 SRTP處理(例如解密)(步驟119)。最后，數(shù)據(jù)分組能夠被輸出到應(yīng) 用(步驟120)。
在上述實(shí)施例的可替換的實(shí)施例中，具有sequence—謡ber = 0模R的所有數(shù)據(jù)分組都將攜帶MAC，所述MAC是在數(shù)據(jù)分組和ROC上計(jì)算的， 但是只有每第R個(gè)標(biāo)簽將會(huì)包含ROC值本身。換言之，發(fā)送器ROC值總 是在對(duì)MAC標(biāo)簽計(jì)算的輸入中使用，而發(fā)送器ROC值僅僅被作為每一第 R個(gè)分組的MAC的輸出的一部分。該實(shí)施例能夠在會(huì)話中的所有數(shù)據(jù)分 組總是應(yīng)該被進(jìn)行完整性保護(hù)的情況下使用。熟悉SRTP協(xié)議的本領(lǐng)域技術(shù)人員將會(huì)"^人識(shí)到對(duì)實(shí)施在此所公開(kāi)的 ROC同步所必需的SRTP框架的唯一改變是使用所接收的發(fā)送器ROC值而 不是本地接收器ROC值來(lái)用于密鑰導(dǎo)出。所有其他操作都能夠通過(guò)XMAC 變換而被在內(nèi)部處理，從SRTP協(xié)議的角度來(lái)看，這可以被祝為"黑盒 子，，。本領(lǐng)域技術(shù)人員還會(huì)注意到，雖然先前的描述僅僅示出擴(kuò)展的 sequence—number如何能夠被傳輸，但是在此所公開(kāi)的原理能夠適于運(yùn) 送其他類型的同步數(shù)椐。類似地，同步數(shù)據(jù)能夠在數(shù)據(jù)分組的其他位置 內(nèi)傳輸(例如，密鑰指示器、有效載荷、分組首部的一部分，等等)而 不是作為MAC標(biāo)簽的一部分進(jìn)行變換。在可替換的實(shí)施例中，可以使用除能夠被R整除以外的方法來(lái)判定 在數(shù)據(jù)分組中是否包含R0C。通常，設(shè)F為將序號(hào)映射到集合(O, 1}的 任何函數(shù)。函數(shù)(F)首先在發(fā)送者和接收者之間被約定。發(fā)送者(和 接收者)然后將F應(yīng)用于給定分組的序號(hào)(s),并且當(dāng)且僅當(dāng)F (s) =1時(shí)，才添加ROC信息。在先前的例子中，當(dāng)且僅當(dāng)s能夠被R整除 時(shí)，F(xiàn) (s)才是l。根據(jù)上文，將會(huì)認(rèn)識(shí)到，本發(fā)明相對(duì)于現(xiàn)有技術(shù)提供了明顯的優(yōu)勢(shì)。的改變。第二，通過(guò)適i地色繪制R參數(shù)值能夠節(jié)省帶寬，這是由于每 第R個(gè)數(shù)據(jù)分組中只有一個(gè)分組會(huì)具有額外的開(kāi)銷。此外，因?yàn)榘l(fā)送器 ROC值被MAC保護(hù)，所以它被安全地傳送，從而避免了拒絕服務(wù)(DoS) 攻擊。此外，對(duì)于接收器而言，在沒(méi)有"標(biāo)記，，或其他開(kāi)銷的情況下辨 別哪些數(shù)據(jù)分組包含再同步信息(即，發(fā)送器ROC值)就是一件很平常 的小事。
權(quán)利要求
1.一種在發(fā)送器中用于數(shù)據(jù)分組的密碼同步的方法，其中所述數(shù)據(jù)分組是使用在因特網(wǎng)工程任務(wù)組(IETF)請(qǐng)求注解(RFC)3711中定義的安全實(shí)時(shí)傳輸協(xié)議(SRTP)來(lái)傳送的，所述方法包括步驟接收數(shù)據(jù)分組以供傳輸；對(duì)所述數(shù)據(jù)分組執(zhí)行SRTP處理，除完整性變換之外；確定用于所述數(shù)據(jù)分組的分組序號(hào)是否能夠被R整除，此處R是由所述發(fā)送器和所述接收器事先約定的整數(shù)；以及如果分組序號(hào)不能被R整除則完成對(duì)所述數(shù)據(jù)分組的SRTP處理；并且將所述數(shù)據(jù)分組傳送到所述接收器；如果分組序號(hào)能夠被R整除則計(jì)算消息鑒別碼(MAC)并將其追加于所述數(shù)據(jù)分組，其中所述MAC是與所述數(shù)據(jù)分組相關(guān)聯(lián)的SRTP密鑰和發(fā)送器翻轉(zhuǎn)計(jì)數(shù)器(ROC)值的函數(shù)，所述發(fā)送器ROC值與所述發(fā)送器中的計(jì)數(shù)器相對(duì)應(yīng)，每當(dāng)所述發(fā)送器中的序號(hào)計(jì)數(shù)器翻轉(zhuǎn)，該計(jì)數(shù)器都遞增；將所述發(fā)送器ROC值追加于所述數(shù)據(jù)分組；完成對(duì)所述數(shù)據(jù)分組的SRTP處理；以及將所述數(shù)據(jù)分組傳送到所述接收器。
2. 如權(quán)利要求1所述的方法，其中對(duì)所述數(shù)據(jù)分組執(zhí)行SRTP處理的 所述步驟包括步驟導(dǎo)出用于對(duì)所述數(shù)據(jù)分組進(jìn)行數(shù)據(jù)保護(hù)的一個(gè)或多 個(gè)密鑰。
3. 如權(quán)利要求1所述的方法，進(jìn)一步包括步驟所述發(fā)送器與所述 接收器進(jìn)行帶外通信以選擇R的值。
4. 如權(quán)利要求1所述的方法，其中所述序號(hào)計(jì)數(shù)器包含16位。
5. 如權(quán)利要求4所述的方法，其中R在1到2"的范圍內(nèi)。
6. 如權(quán)利要求3所述的方法，其中所述發(fā)送器和所述接收器使用從 包括如下項(xiàng)的組中選擇的協(xié)議來(lái)約定所述R的值會(huì)話發(fā)起協(xié)議(SIP); 安全實(shí)時(shí)傳輸(RTSP);和 多媒體因特網(wǎng)密鑰(MIKEY)。
7. —種在接收器中用于數(shù)據(jù)分組的密碼同步的方法，其中所述數(shù)據(jù)分組是使用在因特網(wǎng)工程任務(wù)組(IETF)請(qǐng)求注解(RFC) 3711中定義 的安全實(shí)時(shí)傳輸協(xié)議(SRTP)來(lái)接收的，所述方法包括步驟 接收來(lái)自所述發(fā)送器的數(shù)據(jù)分組；對(duì)所述數(shù)據(jù)分組執(zhí)行SRTP處理，除SRTP密鑰導(dǎo)出之外；確定發(fā)送器翻轉(zhuǎn)計(jì)數(shù)器(ROC)值是否被追加于所述數(shù)據(jù)分組，其 中如果分組序號(hào)能夠被R整除，這表明發(fā)送器ROC值的存在，此處R是 所述發(fā)送器和所述接收器事先約定的整數(shù)；如果所迷數(shù)據(jù)分組不包含發(fā)送器ROC值則使用常規(guī)ROC估計(jì)來(lái)執(zhí)行標(biāo)準(zhǔn)SRTP密鑰導(dǎo)出；如果所迷數(shù)據(jù)分組確實(shí)包含發(fā)送器ROC值則使用該發(fā)送器ROC值而不是接收器ROC值來(lái)執(zhí)行SRTP密鑰導(dǎo)出； 確定所迷數(shù)據(jù)分組的完整性；并且如果所迷數(shù)據(jù)分組的完整性沒(méi)有被確認(rèn)，則丟棄所述數(shù)據(jù)分組；否則如果所述數(shù)據(jù)分組的完整性被確認(rèn)則將所迷接收器ROC值設(shè)置為包含在所述數(shù)據(jù)分組中的發(fā)送器ROC值；從所述數(shù)據(jù)分組中移除所述發(fā)送器ROC值和消息鑒別碼(MAC); 以及完成對(duì)所述數(shù)據(jù)分組的SRTP處理。
8. 如權(quán)利要求7所述的方法，其中確定所述數(shù)據(jù)分組的完整性的所 述步驟包括步驟使用利用所述發(fā)送器ROC值導(dǎo)出的SRTP密鑰來(lái)確定 所述MAC是有效的。
9. 如權(quán)利要求7所述的方法，進(jìn)一步包括步驟所述接收器與所述 發(fā)送器進(jìn)行帶外通信以選擇R的值。
10. 如權(quán)利要求7所述的方法，其中R在1到2"的范圍內(nèi)。
11. 如權(quán)利要求9所述的方法，其中所述發(fā)送器和所述接收器使用 從包括如下項(xiàng)的組中選擇的協(xié)議來(lái)約定所述R的值會(huì)話發(fā)起協(xié)議(SIP); 安全實(shí)時(shí)傳輸(RTSP);和 多4某體因特網(wǎng)密鑰(MIKEY)。
12. —種用于數(shù)據(jù)分組的密碼同步的方法，所述方法包括步驟在發(fā)送器接收數(shù)據(jù)分組以供傳輸?shù)浇邮掌鳎鰯?shù)據(jù)分組包括分組序號(hào)(s);確定所述分組序列的函數(shù)F (s)是否等于預(yù)定值，此處F (s)是 由所述發(fā)送器和所述接收器事先約定的； 如果F (s)等于所述預(yù)定值則計(jì)算代碼并且將其追加于所述數(shù)據(jù)分組，其中所述代碼是與所述 數(shù)據(jù)分組相關(guān)聯(lián)的鑒別密鑰和發(fā)送器翻轉(zhuǎn)計(jì)數(shù)器(ROC)值的函數(shù)，所 述發(fā)送器ROC值與所述發(fā)送器中的計(jì)數(shù)器相對(duì)應(yīng)，每當(dāng)所述發(fā)送器中的 序號(hào)計(jì)數(shù)器翻轉(zhuǎn)，該計(jì)數(shù)器都遞增；將所迷發(fā)送器ROC值追加于所迷數(shù)據(jù)分組；將所述數(shù)據(jù)分組傳送到所述接收器；否則，如果F (s)不等于所述預(yù)定值則在不追加所述發(fā)送器ROC值的情況下將所述數(shù)據(jù)分組傳送到所述 接收器；在所述接收器接收所述數(shù)據(jù)分組；確定所述發(fā)送器ROC值是否被追加于所述數(shù)據(jù)分組，其中如果F( s) 等于所述預(yù)定值，就表明發(fā)送器ROC值的存在； 如果所述數(shù)據(jù)分組確實(shí)包含發(fā)送器ROC值安全性處理包括步驟確定所述數(shù)據(jù)分組的完整性；以及如果所述數(shù)據(jù)分組的完整性沒(méi)有被確認(rèn)，則丟棄所述數(shù)據(jù)分組；否則如果所述數(shù)據(jù)分組的完整性被確認(rèn) 則將所述接收器ROC值設(shè)置為發(fā)送器ROC值； 如果數(shù)據(jù)分組不包括發(fā)送器ROC值則使用所述接收器ROC值或所述ROC值的估計(jì)來(lái)執(zhí)行安全性處理。
13. 如權(quán)利要求12所述的方法，進(jìn)一步包括步驟所述發(fā)送器與所 述接收器進(jìn)行帶外通信以選擇F (s)。
14. 如權(quán)利要求12所述的方法，其中所述序號(hào)計(jì)數(shù)器包含16位。
15. 如權(quán)利要求12所述的方法，其中F(s) =1。
16. 如權(quán)利要求12所述的方法，其中所述發(fā)送器和所述接收器使用從包括如下項(xiàng)的組中選擇的協(xié)議來(lái)約定所述F (s): 會(huì)話發(fā)起協(xié)議(SIP); 安全實(shí)時(shí)傳輸(RTSP);和 多媒體因特網(wǎng)密鑰(MIKEY)。
全文摘要
用于數(shù)據(jù)分組的密碼同步的方法。當(dāng)分組序號(hào)的函數(shù)等于預(yù)定值時(shí)，翻轉(zhuǎn)計(jì)數(shù)器(ROC)值被周期性地追加于數(shù)據(jù)分組并且與數(shù)據(jù)分組一起被傳送。ROC有效地同步數(shù)據(jù)分組的密碼變換。雖然所公開(kāi)的方法通?？捎糜谠S多傳輸協(xié)議，但是它們尤其適用于其中數(shù)據(jù)分組是使用在因特網(wǎng)工程任務(wù)組(IETF)請(qǐng)求注解(RFC)3711中定義的安全實(shí)時(shí)傳輸協(xié)議(SRTP)而被傳送的系統(tǒng)中。
文檔編號(hào)H04L9/12GK101258706SQ200680032814
公開(kāi)日2008年9月3日 申請(qǐng)日期2006年9月8日 優(yōu)先權(quán)日2005年9月9日
發(fā)明者K·諾曼, K·賴思, M·納斯倫德, V·賴托弗塔 申請(qǐng)人:艾利森電話股份有限公司