符合ＭＩＫＥＹ規(guī)范的密鑰更新協(xié)議ＭＩＫＥＹ－Ｒｅｋｅｙ

摘要：MIKEY協(xié)議是一種可應(yīng)用于實(shí)時(shí)的、多媒體通信的密鑰管理協(xié)議。該文基于MIKEY協(xié)議和文獻(xiàn)[6]中的組密鑰管理結(jié)構(gòu)，提出了一種綜合周期和批量密鑰更新策略的密鑰更新協(xié)議MIKEY-Rekey協(xié)議，協(xié)議設(shè)計(jì)考慮到了兩種更新策略的融合、同步問(wèn)題的對(duì)策和PDU的設(shè)計(jì)等問(wèn)題。

關(guān)鍵詞：MIKEY規(guī)范；密鑰更新；協(xié)議設(shè)計(jì)

中圖分類號(hào)：TP393文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1009-3044(2008)29-0320-03

A Rekey Protocol MIKEY-Rekey Based on MIKEY Specification

LIU Yu-jiao

(Center of Computer，Mianyang Normal University，Mianyang 621000，China)

Abstract: MIKEY protocol is a key management scheme that can be used for real-time multimedia applications. In this paper， we design our rekey protocol MIKEY-Rekey based on MIKEY protocol and the group key management architecture in document [6].

Key words: MIKEY specification; rekey; protocol design

多播通信中，密鑰管理為合法用戶分發(fā)和更新密鑰，所有多播數(shù)據(jù)流均由數(shù)據(jù)加密密鑰TEK加密傳輸，TEK由密鑰加密密鑰KEK加密分發(fā)，保證只有合法用戶才能得到TEK并解密多播數(shù)據(jù)流。組密鑰管理是多播安全的核心問(wèn)題之一。組密鑰管理要保證多播會(huì)話的前向安全和后向安全，這就需要對(duì)組密鑰進(jìn)行更新。一個(gè)“好”的密鑰更新協(xié)議必須具備以下性能：

1) 必須保證所有合法用戶及時(shí)地收到密鑰更新消息；

2) 必須指定各通信實(shí)體之間的通信機(jī)制，以及喪失密鑰同步時(shí)的彌補(bǔ)機(jī)制；

3) 在發(fā)送密鑰消息的時(shí)候需要保證密鑰消息傳輸?shù)目煽啃裕?/p>

4) 需要對(duì)密鑰進(jìn)行高效率（減少對(duì)CPU和帶寬的消耗）的更新，特別是在大型動(dòng)態(tài)多播組通信中，這一點(diǎn)關(guān)系到多播通信系統(tǒng)的可用性；

本文基于MIKEY協(xié)議[5]和[6]中的組密鑰管理結(jié)構(gòu)，提出了一種綜合周期和批量密鑰更新策略的密鑰更新協(xié)議MIKEY-Rekey協(xié)議，協(xié)議設(shè)計(jì)考慮到了兩種更新策略的融合、同步問(wèn)題的對(duì)策和PDU的設(shè)計(jì)等問(wèn)題。

1 MIKEY-Rekey的工作過(guò)程概要

GCKS通過(guò)群組注冊(cè)協(xié)議獲得用戶的對(duì)應(yīng)的公鑰，通過(guò)認(rèn)證中心CA查詢用戶證書的合法性。當(dāng)用戶通過(guò)證書驗(yàn)證，就成為了待處理（等待獲得組通信的數(shù)據(jù)加密密鑰TEK）的用戶。當(dāng)用戶要退出組通信，就向GCKS發(fā)送退出消息，GCKS收到此消息之后把該用戶列為待處理用戶。在進(jìn)行密鑰更新的時(shí)候，對(duì)于等待加入的用戶，GCKS發(fā)送單播更新消息；對(duì)于等待退出的用戶，則不把等待退出用戶的相關(guān)信息寫入多播更新消息。即在進(jìn)行密鑰更新的時(shí)候不對(duì)等待退出的用戶進(jìn)行密鑰更新。多播密鑰更新消息是在單播密鑰更新消息上的擴(kuò)展，把需要更新密鑰的用戶所需要的密鑰全部封裝到一條消息里面，用戶根據(jù)自己的ID可以定位自己的密鑰。這種方式大大減少了消息發(fā)送的條數(shù)，但對(duì)于單個(gè)用戶來(lái)說(shuō)接收了一定的冗余信息。

2 MIKEY-Rekey的更新策略分析

2.1 周期更新

GCKS維護(hù)一個(gè)Timer，但Timer為T時(shí)進(jìn)行密鑰更新，具體過(guò)程如下：

1) Timer置0，待處理用戶數(shù)NW置0；

2) 檢查有無(wú)等待加入的用戶，如有，則向等待加入的用戶發(fā)送單播更新消息；

3) 檢查有無(wú)等待退出的用戶，如有，則不把等待退出用戶的相關(guān)信息寫入多播更新消息。形成了多播更新消息后發(fā)送之。

2.2 批量更新

當(dāng)待處理用戶數(shù)NW=N，進(jìn)行密鑰更新，具體更新過(guò)程與周期密鑰更新相同。

現(xiàn)假設(shè)用戶為泊松到達(dá)，參數(shù)為λ。分別計(jì)算僅采用更新策略1或2時(shí)的平均等待處理時(shí)間W：

2.2.1 只采用周期更新策略

假設(shè)在0至T時(shí)刻有n（n≥1）個(gè)用戶到達(dá)。如圖1，ti表示第i個(gè)用戶到達(dá)的時(shí)刻，系統(tǒng)在T時(shí)刻進(jìn)行密鑰更新，設(shè)TW為用戶的等待處理時(shí)間，第i個(gè)用戶的等待處理時(shí)間為T-ti，其中i=1，2，…，n。因此，在0至T時(shí)刻有n個(gè)用戶到達(dá)的情況下，用戶的平均等待處理時(shí)間為：

其中，T1=t1，Ti=ti-ti-1，i=2，3，…，n，T1和Ti服從均值為1/λ的指數(shù)分布，E(T1)=E(Ti)= 1/λ。X(T)為0至T時(shí)刻用戶到達(dá)的個(gè)數(shù)，由泊松過(guò)程的定義可知：

2.2.2 只采用批量更新策略

如圖，N個(gè)用戶仍然為泊松到達(dá)。ti表示第i個(gè)用戶到達(dá)的時(shí)刻，Ti為第i個(gè)用戶與前一個(gè)用戶到達(dá)時(shí)刻的間隔，Ti=ti-ti-1，i=2，3，…，n。則Ti服從均值為1/λ的指數(shù)分布，E(Ti)= 1/λ。因此，用戶的平均等待處理時(shí)間為：

其中，第N個(gè)用戶的等待處理時(shí)間為0。可看出待處理用戶數(shù)NW越大，單位內(nèi)用戶的平均到達(dá)數(shù)越小，用戶平均等待處理時(shí)間越長(zhǎng)。

MIKEY-Rekey的更新策略相當(dāng)與周期更新和批量更新的混合，這種混合更新方式可以防止在動(dòng)態(tài)性不高的情況下，只采用批量更新策略下待處理用戶等待時(shí)間過(guò)長(zhǎng)。

3 密鑰同步問(wèn)題的對(duì)策

3.1 對(duì)于單個(gè)成員變動(dòng)就更新密鑰來(lái)說(shuō)

如果成員變動(dòng)很頻繁就可能導(dǎo)致在接收方密文和密鑰的不同步。

1) X加入，更新采用新密鑰K11；

2) A用K11加密消息；

3) Y加入，更新采用新密鑰K12；

4) A發(fā)送用K11加密的消息；

5) 此時(shí)B可能已經(jīng)獲得了密鑰K12，并用K12解密來(lái)自A的用K11加密的消息，結(jié)果將不能解密。

3.2 在密鑰管理中引入密鑰版本的概念

當(dāng)A作為發(fā)送方發(fā)送加密數(shù)據(jù)的時(shí)候，A把自己持有的TEK的版本號(hào)V(明文)附在密文消息內(nèi)一并發(fā)出。接收方接收到該消息后，將V和自己所持的TEK的版本號(hào)V′進(jìn)行比較，這時(shí)有以下三種可能：

1) V=V′：數(shù)據(jù)發(fā)送方與數(shù)據(jù)接收方保持TEK一致，因而來(lái)自A的密文可以直接用接收方的TEK解讀；

2) V=V′-1：數(shù)據(jù)發(fā)送方未接收到較新版本的TEK，但接收方可以使用前一版本的TEK解開密文。MIKEY-Rekey協(xié)議要求每一個(gè)用戶都保存一個(gè)或多個(gè)歷史密鑰。

3) V=V′+1：數(shù)據(jù)接收方未接收到較新版本的TEK，如果是由于獲取密鑰更新消息的滯后，該接收方只能緩存數(shù)據(jù)，并且這些數(shù)據(jù)最遲應(yīng)該能在T時(shí)間內(nèi)得到解密。

假如V′不符合上述任何一種情況，數(shù)據(jù)接收方直接丟棄報(bào)文，而不作任何進(jìn)一步的處理。

4 協(xié)議的PDU

MIKEY-Rekey協(xié)議中，消息有單播密鑰更新消息、多播密鑰更新消息、離開消息等。下頁(yè)圖3是多播密鑰更新消息的示例：

第一行的前8位表示協(xié)議的版本為1，接下來(lái)的8位表示這條消息是用戶注冊(cè)消息，再接下來(lái)的8位表示緊接著的下一載荷是時(shí)間戳載荷，再接下來(lái)的1位表示發(fā)送方是否需要接收方的驗(yàn)證響應(yīng)消息。接下來(lái)的7位表示密鑰生成要采用的偽隨機(jī)函數(shù)。

第二行為秘密會(huì)話集標(biāo)識(shí)。

第三行的前8位表示秘密會(huì)話編號(hào)。接下來(lái)的8位表示從秘密會(huì)話到安全協(xié)議會(huì)話唯一的映射。后面的16位表明秘密會(huì)話需要?jiǎng)?chuàng)建的安全關(guān)聯(lián)。

第四行的前8位表示下一載荷是隨機(jī)數(shù)載荷，接下來(lái)的8位表示使用的時(shí)間戳類型為NTP-UTC，接下來(lái)的64位表示所使用的時(shí)間戳的值。

第七行的前8位表示下一載荷是ID載荷，接下來(lái)的8位表示隨機(jī)位流長(zhǎng)度為兩個(gè)byte，后面16位為隨機(jī)位流（用*表示）。

第八行的前8位表示下一載荷是ID載荷，接下來(lái)的8位表示ID類型為URI，后面16位表示該ID的長(zhǎng)度為4個(gè)byte。

第九行為4個(gè)byte的GCKS的ID數(shù)據(jù)。

第十行為前8位表示下一載荷是KEK公鑰加密載荷，接下來(lái)的8位表示ID類型為URI，后面16位表示該ID的長(zhǎng)度為4個(gè)byte。

第十一行為4個(gè)byte的U1的ID數(shù)據(jù)。

第十二行為前8位表示下一載荷是ID載荷，接下來(lái)的兩位表示KEK不緩存，接下來(lái)的14位表示加密后KEK數(shù)據(jù)的長(zhǎng)度為16個(gè)byte。接下來(lái)的128位表示加密后的KEK數(shù)據(jù)。

接下來(lái)還有n-1個(gè)用戶的ID載荷及其相應(yīng)的KEK公鑰加密載荷，格式與U1的格式相同，這些數(shù)據(jù)共占了7×(n-1)行。

第7n+10至7n+16行是密鑰數(shù)據(jù)傳輸載荷。

第7n+10行前8位表示下一載荷是簽名載荷，接下來(lái)的8位表示使用的加密算法為AES-CM-128（計(jì)數(shù)器模式下密鑰長(zhǎng)度為128bits的AES算法），后面16位表示加密數(shù)據(jù)長(zhǎng)度為16個(gè)byte。

第7n+11行表示加密數(shù)據(jù)。這是使用KEK來(lái)加密TGK。

第7n+12行表示使用基于SHA-1的HMAC認(rèn)證算法，，接下來(lái)的數(shù)據(jù)表示對(duì)整個(gè)消息的消息認(rèn)證碼。

第7n+17行是對(duì)消息的簽名，前4位表示簽名的類型為PKCS#1簽名，版本1.5，接下來(lái)的12位表示簽名的長(zhǎng)度為6個(gè)byte，接下來(lái)的數(shù)據(jù)為簽名數(shù)據(jù)。此載荷通常作為公鑰分發(fā)方式和DH密鑰交換方式中MIKEY消息的最后一個(gè)載荷。

第7n+19行是二進(jìn)制的明文形式密鑰版本號(hào)。該版本號(hào)的長(zhǎng)度為32位。如果該消息0.5分鐘發(fā)送一次，版本號(hào)從0開始計(jì)數(shù)，直到版本號(hào)中32位都為1的時(shí)候，用時(shí)為4千多年，所以32位的版本號(hào)足夠使用。

5 結(jié)束語(yǔ)

在MIKEY-Rekey協(xié)議中，安全性和性能是一對(duì)矛盾。在批量更新的時(shí)候，短暫的加入/退出延遲其實(shí)是對(duì)前向安全性的略微犧牲，但這換來(lái)的卻是系統(tǒng)通信開銷的顯著下降，并且可以在一定程度上緩解密鑰的不同步問(wèn)題，大大提高了系統(tǒng)的性能。這種略微延遲在一些安全性要求不高的多媒體多播通信（比如付費(fèi)電視）場(chǎng)合是允許的。

在發(fā)送密鑰更新消息的時(shí)候，在多播更新消息中，把對(duì)所有用戶的密鑰更新信息放到了同一條消息里面，這樣雖然可以大大減少發(fā)送消息的條數(shù)，但同時(shí)也帶來(lái)了一定的安全隱患和冗余信息。