亚洲狠狠干,亚洲国产福利精品一区二区,国产八区,激情文学亚洲色图

一種密鑰下發(fā)方法和設(shè)備的制作方法

文檔序號:7656461閱讀:154來源:國知局
專利名稱:一種密鑰下發(fā)方法和設(shè)備的制作方法
技術(shù)領(lǐng)域
本發(fā)明涉及移動通信技術(shù)領(lǐng)域,尤其涉及一種密鑰下發(fā)方法和設(shè)備。
技術(shù)背景隨著移動通信技術(shù)的快速發(fā)展、移動通信網(wǎng)絡(luò)的廣泛使用以及移動通信用戶 數(shù)量的迅猛增長,廣播組播技術(shù)迅速地應(yīng)用于移動通信網(wǎng)絡(luò)中。廣播組播技 術(shù)是指通過共享一條傳輸鏈路,把多媒體數(shù)據(jù)廣播或組播到移動終端。為了在移動通信系統(tǒng)中實現(xiàn)廣播組插、技術(shù),第三代移動通信的標(biāo)準(zhǔn)化組織3GPP和 3GPP2在全球移動通信系統(tǒng)/寬帶碼分多址(GSM/WCDMA, Global System for Mobile Communications/Wideband Code Division Multiple Access) 禾口 CDMA2000網(wǎng)絡(luò)上設(shè)計廣播組播服務(wù),在3GPP中,該項目被叫做多媒體廣播 組播業(yè)務(wù)(MBMS, Multimedia Broadcast Multicast Service),在3GPP2中,該項 目則被稱為廣播和組播業(yè)務(wù)(BCMCS, Broadcast Multicast Service)。為了保證數(shù)據(jù)安全,需要對用戶身份進行鑒別,并對數(shù)據(jù)通過密鑰進行 加密。例如,在MBMS中,用戶設(shè)備(UE, UserEquipment)以及廣播組播業(yè)務(wù) 中心(BM-SC, Broadcast Multicast -Service Center)預(yù)先存儲有MBMS請求密 鑰(MRK, MBMS Request Key), 二者分別通過同樣的算法生成MBMS用戶密 鑰(MUK, MBMS User Key);其中,MRK用于BM-SC在接收到UE發(fā)送的請 求密鑰時,根據(jù)MRK來識別UE; MUK用于BM-SC給UE發(fā)送點對點的 MBMS業(yè)務(wù)密鑰(MSK, MBMS Service Key)時,對MSK進行加密,保護MSK。 參照圖1,為現(xiàn)有技術(shù)中密鑰下發(fā)以及使用所述密鑰進行加密、解密的流程圖, 具體包括以下步驟11 、 UE向BM-SC發(fā)送HTTP Digest Authentication(MRK)消息進行身份鑒 定和密鑰請求;12、 BM-SC根據(jù)MRK對UE進行鑒別,鑒別通過后,通過MUK對MSK進行加密,并通過MIKEY MSK delivery(protect with MUK)消息把含有MSK 的經(jīng)過MUK加密的數(shù)據(jù)包下發(fā)至UE;
13、 UE通過MUK對步驟12發(fā)送的數(shù)據(jù)包進行解密得到MSK;
14、 BM-SC通過MSK對MBMS傳輸密鑰(MTK, MBMS Traffic Key)進孑亍 加密,并通過MIKEY MTK deliveiy(protect with MSK)消息把含有MTK的經(jīng) 過MSK加密的數(shù)據(jù)包下發(fā)至UE;對于手機等用戶終端設(shè)備來說,MTK用于 UE解密接收到的MBMS數(shù)據(jù)。
15、 UE通過步驟13解密得到的MSK對步驟14中下發(fā)的數(shù)據(jù)包進行解 密得到MTK;
16、 BM-SC將內(nèi)容提供者提供的MBMS媒體流通過MTK進行加密并傳 輸至UE;
17、 UE通過步驟15解密得到的MTK對步驟16傳輸?shù)腗BMS媒體流進 行解密,即可得到正確的數(shù)據(jù)。為了保證數(shù)據(jù)傳輸?shù)陌踩?,每隔一定時間,需要更換MSK。在現(xiàn)有技術(shù) 中,當(dāng)BM-SC判斷得知到了修改MSK時限的時候,通過用戶數(shù)據(jù)報協(xié)議(UDP, User Data Protocol)傳輸方式把MIKEY MSK delivery消息傳輸?shù)経E, MIKEY MSK delivery消息中攜帶有MUK加密的修改后的MSK數(shù)據(jù)包;由于UDP 傳輸方式是不可靠的,當(dāng)用戶終端接收到MIKEY MSK delivery(protect with MUK)消息時,通過向BM-SC返回MIKEY ACK(protect w池MUK)確認(rèn)消息 來保證傳輸?shù)目煽啃?。在實現(xiàn)本發(fā)明過程中,發(fā)明人發(fā)現(xiàn)所述現(xiàn)有技術(shù)方案在密鑰下發(fā)過程中, 每次到了更換MSK的時限,BM-SC和UE之間就得通過相應(yīng)的消息來傳輸 MSK,消息條數(shù)很多。同時,由于采用的是UDP這種不可靠的傳輸方式,為 了保證傳輸?shù)目煽啃裕枰l(fā)確認(rèn)消息,而為了保證數(shù)據(jù)安全,需要比較頻 繁地更換MSK,因此,確認(rèn)消息也會很多。而由于MBMS —般會有很多用 戶,這樣一來,導(dǎo)致和BM-SC服務(wù)器交互的消息條數(shù)就會非常多。本發(fā)明實施例所要解決的技術(shù)問題是提供一種密鑰下發(fā)方法和設(shè)備,能 夠減少密鑰下發(fā)過程中交互的消息條數(shù)。為解決上述技術(shù)問題,本發(fā)明實施例的目的是通過以下技術(shù)方案實現(xiàn)的 本發(fā)明實施例提供了一種密鑰下發(fā)方法,該方法包括 接收攜帶有時間相關(guān)信息的密鑰請求;根據(jù)當(dāng)前具體時刻、設(shè)置的密鑰變化頻率,從設(shè)置的密鑰鏈中獲取所述 時間相關(guān)信息所對應(yīng)的至少一個密鑰,并將所述密鑰下發(fā)。 本發(fā)明實施例還提供了一種密鑰下發(fā)設(shè)備,該設(shè)備包括 接收單元,用于接收攜帶有時間相關(guān)信息的密鑰請求; 存儲單元,用于存儲設(shè)置的密鑰變化頻率以及設(shè)置的密鑰鏈;密鑰獲取單元,用于根據(jù)當(dāng)前具體時刻、所述存儲單元中存儲的設(shè)置的 密鑰變化頻率,從所述存儲單元存儲的密鑰鏈中,獲取所述時間相關(guān)信息所 對應(yīng)的至少一個密鑰;密鑰下發(fā)單元,用于將從所述密鑰獲取單元所獲取的密鑰下發(fā)。 從以上技術(shù)方案可以看出,由于本發(fā)明實施例是根據(jù)當(dāng)前具體時刻以及 密鑰變化頻率,從設(shè)置的密鑰鏈中獲取所述時間相關(guān)信息所對應(yīng)的密鑰,并 將所述密鑰一次進行下發(fā),而不需要在每次更換密鑰時分別下發(fā),因此可以 減少密鑰下發(fā)次數(shù),進而可以降低網(wǎng)絡(luò)設(shè)備的資源消耗,節(jié)約網(wǎng)絡(luò)傳輸資源。


圖1為現(xiàn)有技術(shù)中密鑰下發(fā)以及使用所述密鑰進行加密、解密的流程圖; 圖2為本發(fā)明實施例一密鑰下發(fā)方法的流程圖; 圖3為本發(fā)明實施例二密鑰下發(fā)方法的流程圖; 圖4為本發(fā)明實施例三密鑰下發(fā)方法的流程圖; 圖5為本發(fā)明實施例四密鑰下發(fā)方法的流程圖;6圖6為本發(fā)明實施例五密鑰下發(fā)設(shè)備的結(jié)構(gòu)圖; 圖7為本發(fā)明實施例六密鑰下發(fā)設(shè)備的結(jié)構(gòu)圖; 圖8為本發(fā)明實施例七密鑰下發(fā)設(shè)備的結(jié)構(gòu)圖; 圖9為本發(fā)明實施例八密鑰下發(fā)設(shè)備的結(jié)構(gòu)圖。
具體實施方式
為使本發(fā)明實施例的目的、技術(shù)方案及優(yōu)點更加清楚明白,以下參照附 圖,通過在MBMS中的具體應(yīng)用,對本發(fā)明實施例進行詳細(xì)說明。實施例一 ,根據(jù)UE請求的時長的不同,BM-SC會生成用戶請求的時長 所對應(yīng)的密鑰,并將該密鑰向UE下發(fā)。參照圖2,為本發(fā)明實施例一密鑰下發(fā)的流程圖,以下具體說明根據(jù)用戶 請求的時長的不同,BM-SC向UE下發(fā)用戶請求的時長所對應(yīng)的密鑰的過程21、 在BM-SC中設(shè)置密鑰鏈,設(shè)置密鑰變化頻率;所述密鑰鏈可以由一個根密鑰和一個單向函數(shù)生成,例如設(shè)置一個才艮 密鑰為kl,單向函數(shù)為f生成的密鑰鏈,則由kl和f所生成的密鑰鏈中的密鑰 依次為kl、 k2、 k3,......其中,k2二f(kl),k3^f(k2),k3:f(kl),......設(shè)置密鑰變化頻率為IO分鐘一次。例如,從每天的00:00分開始,00:00-00:10分,采用k3加密;00:10-00:20 分,采用k2加密,00:20-00:30分,采用kl加密,......22、 UE發(fā)送攜帶有用戶請求的時長的密鑰請求;例如,UE通過HTTP POST(List of Key Domain ID-MSK ID Pairs)消息向 BM-SC發(fā)送密鑰請求,消息中攜帶有用戶請求的時長。23、 BM-SC根據(jù)當(dāng)前具體時刻、步驟21中設(shè)置的密鑰變化頻率,從步驟 21中所設(shè)置的密鑰鏈中獲取所述用戶請求的時長所對應(yīng)的密鑰;由于步驟21中所設(shè)置的密鑰鏈中的密鑰的關(guān)系為k2=f(kl), k3=f(k2), k3二f^kl),......所以對于利用k3加密的媒體流,擁有kl、 k2的UE可以直接推出k3,所以可以解密k3加密的媒體流,擁有kl的UE可以推出k2,所以可以解 密k2加密的媒體流。設(shè)在00:00分接收到UE發(fā)送的密鑰請求,請求10分鐘的媒體流,則從 密鑰鏈中獲取的密鑰為k3, UE根據(jù)該密鑰可以解開00:00-00:10分的媒體流, 00:10分之后的媒體流根據(jù)k3無法解開。設(shè)在00:07分接收到UE發(fā)送的密鑰請求,請求10分鐘的媒體流,則從 密鑰鏈中獲取的密鑰為k2, k2可以解開00:10-00:20分的々某體流,由于UE可 以根據(jù)k2推出k3,可以解開00:07-00:10分的媒體流,總之,用戶可以解開 00:07-00:20分的媒體流,能夠滿足用戶要求,但00:20分之后的媒體流UE無 法打開。24、 BM-SC向UE下發(fā)所獲取的密鑰。BM-SC通過MIKEYMSK delivery消息向UE下發(fā)所獲取的密鑰。由于仍然采用UDP傳輸方式,為了保證可靠性,當(dāng)BMSC接收到UE發(fā) 送的HTTP POST(List of Key Domain ID-MSK ID Pairs)消息時,會向UE返回 響應(yīng)消息HTTP 200 OK,當(dāng)UE接收到BM-SC下發(fā)的密鑰時,會返回MIKEY ACK確認(rèn)消息,不再詳細(xì)描述。在現(xiàn)有技術(shù)中,每過10分鐘,UE和BM-SC就要交互一次消息來更換密 鑰。如果用戶收看的節(jié)目時長60分鐘,那么UE和BM-SC之間由于更換密 鑰需要交互6次消息,加上為了保證UDP傳輸安全所發(fā)送的確認(rèn)消息,則增 消息交互次數(shù)又增加一倍。而本發(fā)明實施例中不論用戶請求的時長有多長, 只需要一次消息交互,即可完成所有的密鑰下發(fā)。對于MBMS這樣擁有大量 用戶的業(yè)務(wù),可以節(jié)約大量的交互消息,因此可以減少BM-SC服務(wù)器資源的 消耗,節(jié)約網(wǎng)絡(luò)傳輸資源。實施例二,為了保證數(shù)據(jù)安全,可以在實施例一基礎(chǔ)上,采用鑒別用戶 身份以及不斷更換設(shè)置的密鑰鏈的根密鑰的方法來保證密鑰的安全性。參照圖3,為本發(fā)明實施例二密鑰下發(fā)方法的流程圖,以下進行詳細(xì)說明31、 在BM-SC中設(shè)置密鑰鏈,設(shè)置根密鑰的更新頻率,設(shè)置密鑰變化頻率;仍然設(shè)置一個根密鑰為kl,單向函數(shù)為f生成的密鑰鏈,各個密鑰依次為 kl、 k2、 k3.......,其中,k2-f(kl),k3:f(k2),k3-f(kl),......設(shè)置密鑰變化頻率為IO分鐘一次。假設(shè)從每天的00:00分開始,00:00-00:10分,采用k3加密;00:10-00:20 分,采用k2加密,00:20-00:30分,采用kl加密,......設(shè)置根密鑰的更新頻率為30分鐘一次,設(shè)在00:30分之后,使用kl,作為 根密鑰,單向函數(shù)仍為f,則可以得到k2』f(k1,), k3,=f(k2,), k3,-f(kr),......32、 UE發(fā)送攜帶有用戶請求的時長的密鑰請求;UE可以通過攜帶有用戶請求的時長的HTTP POST(List of Key Domain ID-MSK ID Pairs)消息向BM-SC發(fā)送密鑰請求。33、 BM-SC向UE發(fā)送鑒權(quán)請求;BM-SC向UE發(fā)送HTTP 401 www-Authenticate消息,在消息的頭字段 www-Authenticate至少包含一個質(zhì)詢來指定適用于該領(lǐng)域的鑒權(quán)機制和參數(shù)。34、 UE使用合適的證書重新發(fā)起密鑰請求;當(dāng)UE接收到HTTP 401 www-Authenticate消息時,向BM-SC發(fā)送HTTP POST Authorization Request(List of Key Domain ID-MSK ID Pairs)消息重新發(fā) 起密鑰請求;35、 當(dāng)鑒權(quán)通過時,BM-SC向UE返回響應(yīng)消息;鑒權(quán)通過,BM-SC向用戶返回HTTP 200 OK Authentication-Info(Status Codes)響應(yīng)消息,消息中攜帶有鑒權(quán)通過的具體狀態(tài)碼。36、 BM-SC根據(jù)當(dāng)前具體時刻、步驟31中設(shè)置的密鑰變化頻率,從步驟 31中所設(shè)置的密鑰鏈中獲取所述用戶請求的時長所對應(yīng)的密鑰;對于在00:00分接收到UE發(fā)送的密鑰請求,如果用戶請求的時長小于等于30分鐘,獲取對應(yīng)時段的密鑰與實施例一中所獲取的密鑰相同,不再詳細(xì) 描述。對于在00:00分接收到UE發(fā)送的密鑰請求,如果用戶請求的時長大于30 分鐘,則可按照下述方法獲取用戶請求的時長所對應(yīng)的密鑰。例如,在00:00分接收到UE發(fā)送的密鑰請求為40分鐘,由于通過kl可 以解開00:00-00:30分的媒體流,而k3,可以解開00:30-00:40分的媒體流,故 從密鑰鏈中獲取的密鑰為kl和k3,。如果在00:00分接收到UE發(fā)送的密鑰請求為50分鐘,由于通過kl可以 解開00:00-00:30分的媒體流,而k2,可以解開00:40-00:50分的媒體流,通過 k2,可以推出k3,, k3,可以解開00:30-00:40分的媒體流,故從密鑰鏈中獲取的 密鑰為kl和k2,。如果在00:00分接收到UE發(fā)送的密鑰請求為60分鐘,由于通過kl可以 解開00:00-00:30分的媒體流,而kl,可以解開00:50-01:00分的媒體流,通過 kl,可以推出k2,, k2,可以解開00:40-00:50分的媒體流,進而通過k2,可以推 出k3,, k3,可以解開00:30-00:40分的媒體流,故從密鑰鏈中獲取的密鑰為kl 和kl,。以此可以類推用戶請求的時長大于60分鐘的情況,不再——描述。37、 BM-SC向UE下發(fā)所生成的密鑰;BM-SC通過MIKEY MSK delivery消息向UE下發(fā)所生成的密鑰。38、 UE接收到密鑰后向BM-SC返回確i人消息。由于使用的為UDP的傳輸方式,為了保證傳輸?shù)目煽啃?,UE返回MIKEY ACK確^人消息??梢?,該實施例以一定的頻率更新生成密鑰鏈的根密鑰,可以增強數(shù)據(jù) 的安全性;而對用戶身份的鑒權(quán),可以防止非法用戶的非法請求。為了保證數(shù)據(jù)安全,也可以按照設(shè)置的頻率更換密鑰鏈的單向函數(shù)或同 時更換根密鑰及單向函數(shù)。在下發(fā)密鑰前,還可以對所生成的密鑰進行加密后再下發(fā),以更好地保 證數(shù)據(jù)安全。BM-SC根據(jù)當(dāng)前具體時刻、設(shè)置的所述密鑰變化頻率,在確定的時間段 內(nèi)從所述設(shè)置的密鑰鏈中獲取該時間段內(nèi)對應(yīng)的密鑰,采用該密鑰對媒體流 進行加密并下發(fā)。除了采用下發(fā)的密鑰對媒體流進行加密外,還可以對其他 數(shù)據(jù)進行加密,例如,另外一種密鑰。而且,這樣可以更好地保證數(shù)據(jù)安全。例如,BM-SC根據(jù)當(dāng)前具體時刻、密鑰變化頻率,在確定的時間段內(nèi)從 所述密鑰鏈中選取該時間段對應(yīng)的MSK對MTK信息進行加密并下發(fā),然后 通過MTK消息對媒體流進行加密并下發(fā),相應(yīng)地,UE通過從先前BM-SC 下發(fā)的MSK中選取該時間段內(nèi)應(yīng)選取的MSK對MTK信息進行解密,再利 用MTK對接收到的媒體流進行解密。實施例三,為了便于UE能夠快速地使用適當(dāng)?shù)拿荑€對^(某體流進行解密, BM-SC可以給不同的密鑰添加標(biāo)識。參照圖4,為本發(fā)明實施例三下發(fā)密鑰方法的流程圖,以下具體說明為所 獲取的密鑰添加標(biāo)識時的密鑰下發(fā)的具體流程41、 在BM-SC中設(shè)置密鑰鏈,設(shè)置密鑰鏈中根密鑰的更新頻率,設(shè)置密 鑰鏈中的密鑰變化頻率;42、 UE發(fā)送攜帶有用戶請求的時長的密鑰請求;43、 BM-SC根據(jù)當(dāng)前具體時刻、步驟41中設(shè)置的密鑰變化頻率,從設(shè)置 的密鑰鏈中獲取所述用戶請求的時長所對應(yīng)的密鑰;44、 對步驟43所獲取的密鑰進行加密并添加標(biāo)識;標(biāo)識可以是索引號,假設(shè)從密鑰鏈中所獲取的密鑰為kl、 k2,,為kl添 加的索引號為1,為k2,添加的索引號為2,可對索引號進行加密也可以不加 密。并為下發(fā)的媒體流添加相應(yīng)的標(biāo)識,例如對經(jīng)過MTK加密的媒體流根據(jù) 密鑰的不同添加3于應(yīng)的標(biāo)識。標(biāo)識也可以直接是時間戳,例如,kl的時間戳為00:00-00:30, k2,的時間戳為00:30-00:50。45、 BM-SC向UE下發(fā)所獲取的密鑰;46、 UE根據(jù)標(biāo)識在需要時采用適當(dāng)?shù)拿荑€對媒體流進行解密。如果標(biāo)識為索引號,則UE根據(jù)媒體流中的索引號選擇對應(yīng)的密鑰對媒體 流進行解密。如果所述標(biāo)識為時間^t, UE將時間與BM-SC時間保持同步,通過判斷 時間確定正確的密鑰,如果此時UE時間在00:00-00:30范圍內(nèi),則采用kl進 行解密;如果此時UE時間在00:30-00:50范圍內(nèi),則釆用k2,進行解密??梢?,本實施例通過對所獲取的用戶請求的時長所對應(yīng)的每個密鑰都添 加對應(yīng)的標(biāo)識,當(dāng)用戶接收到含有該標(biāo)識的媒體流時,直接通過媒體流中的 標(biāo)識找到對應(yīng)的密鑰,從而實現(xiàn)快速解密。而通過設(shè)置密鑰鏈中根密鑰的更 新頻率,以及對所獲取的密鑰加密后再下發(fā),增強了媒體流數(shù)據(jù)傳輸?shù)陌踩.?dāng)然,BM-SC也可以不對下發(fā)的密鑰添加標(biāo)識,當(dāng)UE接收到密鑰時, 可以采取逐個嘗試的方法選擇正確的密鑰對接收到的媒體流或其他數(shù)據(jù)進行 解密。對于移動通信領(lǐng)域的組播和廣播技術(shù),從業(yè)務(wù)數(shù)據(jù)方面來看,組播廣播 都對用戶進行收費,而從承載方面來看,組播對用戶和內(nèi)容提供商進行收費, 廣播只對內(nèi)容提供商進行收費?,F(xiàn)有技術(shù)中主要是根據(jù)用戶簽約情況來收費, 例如包月付費業(yè)務(wù)。但是根據(jù)用戶的簽約情況進行計費的方式無法滿足用戶 的需要,例如,用戶僅在一定的時段內(nèi)希望享受MBMS,而在其他時段內(nèi)并 不需要;或者, 一個用戶對一個節(jié)目首先試看幾分鐘,再決定是否繼續(xù)看下 去,則現(xiàn)有的根據(jù)用戶的簽約情況進行計費的方式無法滿足這部分用戶的需 求。實施例四,在以上各實施例基礎(chǔ)上,下面具體說明在下發(fā)密鑰的過程中 如何實現(xiàn)分時計費。參照圖5,為本發(fā)明實施例四密鑰下發(fā)方法的流程圖,具體包括步驟51 、 UE發(fā)送攜帶有用戶請求的時長的密鑰請求至BM-SC;在MBMS業(yè)務(wù)中,首先BM-SC通過service announcement消息把業(yè)務(wù)服 務(wù)清單通過廣播的形式通知給UE, UE選擇自己要加入的媒體流,并通過 HTTP POST消息通知BM-SC,在該消息中,含有時長選項,用于UE選擇或 填寫希望享受的服務(wù)的時長。52、 BM-SC根據(jù)密鑰請求中所攜帶的用戶請求的時長,以及設(shè)置的單位 時長內(nèi)費用,計算并扣除用戶請求的時長所對應(yīng)的費用。例如用戶請求的時長為40分鐘,設(shè)置的單位時長費用為每IO分鐘一元, 則應(yīng)扣除的用戶費用為4元。仍然假設(shè)密鑰更換頻率為IO分鐘一次,設(shè)置的密鑰鏈的根密鑰為kl,單向函數(shù)為f,則密鑰鏈中各個密鑰依次為kl、 k2、 k3.......,其中,k2=f(kl),k3=f(k2), k3=f2(kl),......假設(shè)從每天的00:00分開始,00:00-00:10分,采用k3加密;00:10-00:20分,采用k2加密,00:20-00:30分,采用kl加密,......如果在00:07分接收到UE發(fā)送的攜帶有時長為10分鐘的密鑰請求,則 該用戶所使用的密鑰應(yīng)該無法打開00:17分之后的媒體流,但是,由于密鑰要 在一定的時間內(nèi)才會改變,即到00:20分,所以用戶可能會多享受幾分鐘的服 務(wù)。密鑰更換頻率越快,計費越精確。在以上各實施例及具體實施方式
中,所述的用戶請求的時長也可以是其 他的時間相關(guān)信息,例如,用戶請求的一定的時間段,或者用戶所選擇的服 務(wù)節(jié)目,也可以是這幾項中任意一項或多項的組合。例如,BM-SC可以根據(jù) 用戶所選擇的服務(wù)節(jié)目,得知該節(jié)目播出的時長及具體時間。用戶所請求的 時間段也可以是未來某一段具體的時間,比如,當(dāng)前時間為00:00分,用戶可 以請求01:00-01:40分時長內(nèi)的i某體流。以上對本發(fā)明實施例所提供的密鑰下發(fā)方法進行了詳細(xì)的說明,為了使 本領(lǐng)域技術(shù)人員更好地實現(xiàn)本發(fā)明實施例所提供的技術(shù)方案,以下對本發(fā)明實施例所提供的密鑰下發(fā)設(shè)備進行詳細(xì)說明。參照圖6,為本發(fā)明實施例五密鑰下發(fā)設(shè)備的結(jié)構(gòu)圖,該密鑰下發(fā)設(shè)備包括接收單元61,用于接收攜帶有時間相關(guān)信息的密鑰請求;存儲單元62,用于存儲設(shè)置的密鑰變化頻率以及設(shè)置的密鑰鏈;密鑰獲取單元63,用于根據(jù)當(dāng)前具體時刻、所述存儲單元62中存儲的設(shè) 置的密鑰變化頻率,從所述存儲單元62存儲的設(shè)置的密鑰鏈中獲取所述時間 相關(guān)信息所對應(yīng)的至少一個密鑰;密鑰下發(fā)單元64,用于將所述密鑰獲取單元63獲取的密鑰下發(fā)。采用本實施例中所述密鑰下發(fā)設(shè)備,不論用戶請求的時長有多長,只需 要一次消息交互,即可完成所有的密鑰下發(fā)。對于MBMS這樣擁有大量用戶 的業(yè)務(wù),可以節(jié)約大量的交互消息,因此可以節(jié)約服務(wù)器資源以及網(wǎng)絡(luò)傳輸 資源。上述密鑰下發(fā)設(shè)備還可進一步包括加密單元、數(shù)據(jù)下發(fā)單元,其中加密單元,用于根據(jù)當(dāng)前具體時刻、密鑰變化頻率,在確定的時間段內(nèi) 采用從所述密鑰鏈中獲取的該時間段對應(yīng)的密鑰對數(shù)據(jù)進行加密;數(shù)據(jù)下發(fā)單元,用于將加密單元加密后的數(shù)據(jù)進行下發(fā)。數(shù)據(jù)下發(fā)單元下發(fā)的數(shù)據(jù)可以是媒體流,也可以是另一個密鑰,以更好 地保證數(shù)據(jù)安全。參照圖7,為本發(fā)明實施例六密鑰下發(fā)設(shè)備的結(jié)構(gòu)圖,為了保證數(shù)據(jù)安全, 可以在上述密鑰下發(fā)設(shè)備中,設(shè)置一個密鑰鏈生成單元71,用于通過一個根 密鑰和一個單向函數(shù)生成所述密鑰鏈。通過密鑰生成單元71,可以根據(jù)具體情況來決定某段時間內(nèi)生成的密鑰 鏈中密鑰的個數(shù)。例如設(shè)置一個根密鑰為kl,單向函數(shù)為f生成的密鑰鏈, 則由kl和f所生成的密鑰鏈中的密鑰依次為kl、 k2、 k3,......其中,k2=f(kl),k3=f(k2), k3=f2(kl),……在實施例六基礎(chǔ)上,為了保證數(shù)據(jù)的安全性,可以進一步設(shè)置參數(shù)更新 單元,參照圖8,為本發(fā)明實施例七密鑰下發(fā)設(shè)備結(jié)構(gòu)圖,該密鑰下發(fā)設(shè)備中,在圖7所示的密鑰下發(fā)設(shè)備基礎(chǔ)上,進一步增加參數(shù)更新單元81,用于按照設(shè)置的頻率更新所述密鑰鏈生成單元中的根密鑰和/或單向函數(shù)。在以上各實施例所述的密鑰下發(fā)設(shè)備中,還可包括密鑰加密單元,用于 對所述密鑰獲取單元所獲取的密鑰進行加密,加密后再由所述密鑰下發(fā)單元64將加密后的密鑰進行下發(fā),從而可以保證數(shù)據(jù)傳輸?shù)陌踩浴榱吮阌赨E能夠快速地使用適當(dāng)?shù)拿荑€對媒體流等數(shù)據(jù)進行解密,密鑰 下發(fā)設(shè)備還可包括標(biāo)識添加單元,用于對所述密鑰獲取單元63所獲取的密鑰 添力口標(biāo)識。標(biāo)識具體可為索引號或時間戳。對于移動通信領(lǐng)域的組播和廣播技術(shù),從業(yè)務(wù)數(shù)據(jù)方面來看,組播廣播 都對用戶進行收費,而從承載方面來看,組播對用戶和內(nèi)容提供商進行收費, 廣播只對內(nèi)容提供商進行收費?,F(xiàn)有技術(shù)中主要是根據(jù)用戶簽約情況來收費, 例如包月付費業(yè)務(wù)。但是根據(jù)用戶的簽約情況進行計費的方式無法滿足用戶 的需要,例如,用戶僅在某一時段內(nèi)希望享受MBMS,而在其他時段內(nèi)并不 需要。或者, 一個用戶對一個節(jié)目首先試看幾分鐘,再決定是否繼續(xù)看下去, 則現(xiàn)有的根據(jù)用戶簽約的情況進行計費的方式無法滿足這部分用戶的需求。實施例八,密鑰下發(fā)設(shè)備在以上實施例和實施方式的基礎(chǔ)上,還可進一 步包括費用管理單元,用于實現(xiàn)對用戶分時收費,參照圖9,為本發(fā)明實施例 八密鑰下發(fā)設(shè)備的結(jié)構(gòu)圖,該密鑰下發(fā)設(shè)備進一步包括費用管理單元91,用 于根據(jù)所述時間相關(guān)信息,以及設(shè)置的單位時長內(nèi)的費用,進行計費管理。 例如,可以根據(jù)所述時間相關(guān)信息,以及設(shè)置的單位時長內(nèi)的費用,計算并 扣除時間相關(guān)信息所對應(yīng)的費用。在以上實施例所說的密鑰下發(fā)設(shè)備中,所述的時間相關(guān)信息為用戶請求 的時長、用戶請求的時間段、用戶請求的服務(wù)節(jié)目至少其中一項。所述的密鑰下發(fā)設(shè)備,在MBMS中,可以由BM-SC來實現(xiàn)。是可以通過程序來指令相關(guān)的硬件來完成,所述的程序可以存儲于一計算機 可讀取存儲介質(zhì)中,該程序在執(zhí)行時,包括如下步驟接收攜帶有時間相關(guān)信息的密鑰請求;根據(jù)當(dāng)前具體時刻、設(shè)置的密鑰變化頻率,從設(shè)置的密鑰鏈中獲取所述 時間相關(guān)信息所對應(yīng)的至少一個密鑰,并將所述密鑰下發(fā)。所述的存儲介質(zhì),如ROM/RAM、磁碟、光盤等。從以上各實施例可以看出,本發(fā)明具有如下有益效果由于可以根據(jù)當(dāng)前具體時刻、設(shè)置的密鑰變化頻率,從設(shè)置的密鑰鏈中 獲取所述時間相關(guān)信息所對應(yīng)的密鑰,并將所述密鑰一次下發(fā),不需要像現(xiàn) 有技術(shù)中每改變一次密鑰就要下發(fā)一次,因而可以減少密鑰下發(fā)次數(shù),因而 可以降低網(wǎng)絡(luò)設(shè)備的資源消耗,節(jié)約網(wǎng)絡(luò)傳輸資源。特別是為了保證消息在UDP傳輸方式下的可靠性,減少密鑰下發(fā)次數(shù), 同時也減少了確認(rèn)消息的次數(shù),尤其是當(dāng)用戶數(shù)據(jù)很多時,可以節(jié)約大量的 網(wǎng)絡(luò)設(shè)備以及網(wǎng)絡(luò)傳輸資源。通過對下發(fā)的密鑰進行加密,增強了下發(fā)的密鑰的安全性。而通過對所生成的密鑰添加標(biāo)識,便于UE在需要的時候快速選擇正確的 密鑰進行解密。另外,通過根據(jù)密鑰請求中的時間相關(guān)信息以及單位時長內(nèi)的費用,計 算并扣除時間相關(guān)信息所對應(yīng)的費用,從而可以實現(xiàn)分時段收費,滿足用戶 需求。以上對本發(fā)明所提供的一種密鑰下發(fā)方法和設(shè)備通過實施例進行了詳細(xì) 介紹,以上實施例的說明只是用于幫助理解本發(fā)明的方法及其思想;同時, 對于本領(lǐng)域的一般技術(shù)人員,依據(jù)本發(fā)明的思想,在具體實施方式
及應(yīng)用范 圍上均會有改變之處,綜上所述,本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。
權(quán)利要求
1.一種密鑰下發(fā)方法,其特征在于,包括接收攜帶有時間相關(guān)信息的密鑰請求;根據(jù)當(dāng)前具體時刻、設(shè)置的密鑰變化頻率,從設(shè)置的密鑰鏈中獲取所述時間相關(guān)信息所對應(yīng)的至少一個密鑰,并將所述密鑰下發(fā)。
2. 如權(quán)利要求1所述的密鑰下發(fā)方法,其特征在于,進一步包括根據(jù)當(dāng)前具體時刻、設(shè)置的所述密鑰變化頻率,在確定的時間段內(nèi)采用 從所述密鑰鏈中獲取的該時間段對應(yīng)的密鑰對數(shù)據(jù)進行加密并下發(fā)。
3. 如權(quán)利要求1或2所述的密鑰下發(fā)方法,其特征在于,所述密鑰鏈由 一個根密鑰和一個單向函數(shù)生成。
4. 如權(quán)利要求3所述的密鑰下發(fā)方法,其特征在于,進一步包括 按照設(shè)置的頻率更換所述根密鑰、單向函數(shù)至少其中一個。
5. 如權(quán)利要求2所述的密鑰下發(fā)方法,其特征在于,將所述密鑰下發(fā)之 前進一步包括對所述密鑰添加標(biāo)識。
6. 如權(quán)利要求5所述的密鑰下發(fā)方法,其特征在于,所述標(biāo)識為索引號 或者時間戳。
7. 如權(quán)利要求1所述的密鑰下發(fā)方法,其特征在于,進一步包括根據(jù)所述時間相關(guān)信息,以及設(shè)置的單位時長內(nèi)的費用,進行相應(yīng)的計 費處理。
8. 如權(quán)利要求1或7所述的密鑰下發(fā)方法,其特征在于,所述時間相關(guān) 信息具體為用戶請求的時長、用戶請求的時間段、用戶請求的服務(wù)節(jié)目至少 其中一項。
9. 一種密鑰下發(fā)設(shè)備,其特征在于,包括 接收單元,用于接收攜帶有時間相關(guān)信息的密鑰請求; 存儲單元,用于存儲設(shè)置的密鑰變化頻率以及設(shè)置的密鑰鏈;密鑰獲取單元,用于根據(jù)當(dāng)前具體時刻、所述存儲單元中存儲的設(shè)置的 密鑰變化頻率,從所述存儲單元存儲的密鑰鏈中,獲取所述時間相關(guān)信息所對應(yīng)的至少一個密鑰;密鑰下發(fā)單元,用于將從所述密鑰獲取單元所獲取的密鑰下發(fā)。
10. 如權(quán)利要求9所述的密鑰下發(fā)設(shè)備,其特征在于,進一步包括加密單元,用于根據(jù)當(dāng)前具體時刻、密鑰變化頻率,在確定的時間段內(nèi) 采用從所述密鑰鏈中獲取的該時間段對應(yīng)的密鑰對數(shù)據(jù)進行加密;數(shù)據(jù)下發(fā)單元,用于將加密單元加密后的數(shù)據(jù)進行下發(fā)。
11. 如權(quán)利要求9所述的密鑰下發(fā)設(shè)備,其特征在于,進一步包括密鑰 鏈生成單元,用于通過一個根密鑰和一個單向函數(shù)生成所述密鑰鏈。
12. 如權(quán)利要求11所述的密鑰下發(fā)設(shè)備,其特征在于,進一步包括參 數(shù)更新單元,用于按照設(shè)置的頻率更新所述密鑰鏈生成單元中的根密鑰和/或 單向函數(shù)。
13. 如權(quán)利要求9至12任一項所述的密鑰下發(fā)設(shè)備,其特征在于,進一 步包括標(biāo)識添加單元,用于對所述密鑰獲取單元所獲取的密鑰添加標(biāo)識。
14. 如權(quán)利要求9所述的密鑰下發(fā)設(shè)備,其特征在于,進一步包括費用 管理單元,用于根據(jù)所述時間相關(guān)信息,以及設(shè)置的單位時長內(nèi)的費用,進 行相應(yīng)的計費處理。
全文摘要
本發(fā)明屬于移動通信技術(shù)領(lǐng)域,公開了一種密鑰下發(fā)方法和設(shè)備,該密鑰下發(fā)方法包括步驟接收攜帶有時間相關(guān)信息的密鑰請求;根據(jù)當(dāng)前具體時刻、設(shè)置的密鑰變化頻率,從設(shè)置的密鑰鏈中獲取所述時間相關(guān)信息所對應(yīng)的至少一個密鑰,并將所述密鑰下發(fā)。該方法能夠通過一次消息交互滿足用戶所請求的時間相關(guān)信息所對應(yīng)的密鑰,而不需要當(dāng)密鑰更換時,分別下發(fā),因此可以減少密鑰下發(fā)次數(shù),進而可以降低網(wǎng)絡(luò)設(shè)備的資源消耗,節(jié)約網(wǎng)絡(luò)傳輸資源。
文檔編號H04Q7/22GK101330379SQ20071012304
公開日2008年12月24日 申請日期2007年6月22日 優(yōu)先權(quán)日2007年6月22日
發(fā)明者呂東俊, 王曉蕓 申請人:華為技術(shù)有限公司
網(wǎng)友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點贊!
1