一種分配媒體流密鑰的方法和多媒體子系統的製作方法

2023-06-13 20:42:51 5

專利名稱：：一種分配媒體流密鑰的方法和多媒體子系統的製作方法
技術領域：
：本發明涉及媒體流加密技術，特別是涉及一種分配媒體流密鑰的方法多媒體子系統。
背景技術：
：士某體流一般基於實時傳輸十辦i義(RTP，Real-timeTransportProtocol)進行傳輸，這裡的所述的媒體流為音頻媒體流、視頻媒體流等。但由於RTP協議本身並不涉及安全問題，使媒體流在傳輸過程中存在洩密、被攻擊等安全隱患。為了加強媒體流在傳輸過程中的安全性，目前已提出多種生成和分配密鑰的方法，即密鑰協商方法。之後，終端可以利用分配的密鑰實現媒體流的傳輸，達到安全傳輸媒體流的目的。在現有技術中，密鑰協商方法中有兩種典型方法一種是多媒體網際網路密鑰(MIKEY)公鑰模式，另一種是MIKEYDH模式。其中，MIKEY公鑰模式的基本思想是由主叫終端生成密鑰和信封密鑰，所述密鑰用信封密鑰進行加密，信封密鑰再利用被叫終端證書的公鑰進行加密，然後將加密後的密鑰通過MIKEY協議發送到被叫終端，被叫終端解密後獲得密鑰，完成密鑰協商過程。在MIKEY公鑰模式中，為了保障密鑰協商過程的安全、順利地進行，要求主叫終端和被叫終端之間進行時鐘同步，並具備公鑰基礎設施(PKI)系統的支持。而實際應用中，實現時鐘同步以及PKI系統支持比較複雜，不利於密鑰協商的實現。比如在電話會議中，存在多個需要傳輸媒體流的終端。如果要對多個終端的媒體流加密，則需要將多個終端進行時鐘同步，這大大增加了密鑰協商的困難。又比如主叫終端和被叫終端為普通的移動終端，而由於移動終端數量大，將很難完成PKI系統中證書管理等工作，無法順利進行密鑰協商。MIKEYDH模式的基本思想是在主叫終端和被叫終端分別生成DH值，再利用MIKEY協議交換彼此的DH值，然後根據雙方的DH值產生密鑰。MIKEYDH才莫式也需要進行時鐘同步，而且實現MIKEYDH才莫式非常複雜，計算量大，對終端性能要求高，不利於密鑰協商的實現。另外，實際應用中，運營商為了安全機構滿足合法監聽的要求，需要獲得媒體流中的密鑰。而現有技術中，只有參與交互的終端才可以獲得密鑰，這裡所述參與交互的終端可能為主叫和被叫兩個終端，也可能為多個終端，任何參與交互之外的第三方都無法獲得密鑰，即無法滿足合法監聽的要求。
發明內容有鑑於此，本發明的主要目的在於提供一種分配媒體流密鑰的方法和多媒體子系統，可以在保證鏈路安全的條件下，避免時鐘同步、PKI支持、證書管理等過程，減少生成密鑰的複雜度，便於媒體流加密業務的推廣。為了達到上述第一個目的，本發明提出的技術方案為一種分配媒體流密鑰的方法，預先設置生成密鑰的安全應用伺服器，當主叫終端發起呼叫時，該方法包括A、安全應用伺服器根據呼叫請求消息判斷主叫終端所屬域與被叫終端所屬域是否已籤署密鑰分發協議，如果已經籤署，執行步驟B後退出本流程；否則執行步驟C;B、安全應用伺服器根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的同一個密鑰分配給主叫終端和被叫終端；C、安全應用伺服器根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的密鑰分配給自身所在一側的終端。為了達到上述第二個目的，本發明提出的技術方案為一種多4某體子系統，至少包括主叫終端和被叫終端，該系統還包括安全應用伺服器，用於根據主叫終端所屬域與被叫終端所屬域的籤約情況確定加密方式，根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的密鑰發送給終端。綜上所迷，本發明提出的一種分配媒體流密鑰的方法和多媒體系統，由於主叫終端和被叫終端自身並不生成密鑰，而是安全應用伺服器生成密鑰的，無需進行時鐘同步，也無需PKI體系的支持，可以大大降低媒體流密鑰協商的複雜度，便於媒體流加密業務的推廣。圖l是本發明的流程圖；圖2是方法實施例一的消息流示意圖；圖3是方法實施例二的消息流示意圖；圖4是方法實施例三的消息流示意圖；圖5是方法實施例四的消息流示意圖；圖6是方法實施例五的消息流示意圖；圖7是本發明系統基本結構示意圖；圖8是系統實施例的基本結構示意圖。具體實施方式為使本發明的目的、技術方案和優點更加清楚，下面將結合附圖及具體實施例對本發明作進一步地詳細描述。本發明的基本思想是根據主叫終端所屬域和被叫終端所屬域籤署密鑰分發協議的情況確定加密方式，如果籤署了協議，就採用端到端加密協商方式獲取相應的密鑰，如果沒有籤署協議，就利用分段加密方式獲取相應的密鑰。根據主叫側開通加密業務的情況，可以將本發明分為兩種類型，一種是主加側將加密業務作為基本業務的類型，另一種是主叫側將加密業務作為增值業務的類型。對於主叫側將加密業務作為基本業務的情況下，不管是採用端到端加密協商方法，還是採用分段加密方式，主叫側安全應用伺服器都將生成密鑰，其方法可以如圖1所示。預先設置生成密鑰的安全應用伺服器，當主叫終端發起呼叫時，終端設備獲取媒體流密鑰的方法包括以下步驟步驟101:安全應用伺服器根據呼叫請求消息判斷主叫終端所屬域與被叫終端所屬域是否已籤署密鑰分發協議，如果已經籤署，執行步驟102後退出本流程；否則執行步驟103;呼叫請求消息可以攜帶有用戶標識，安全應用伺服器根據用戶標識可以查詢主叫終端運營商與被叫終端運營商籤署密鑰分發協議的相關信息。比如如果籤署了協議，可事先將籤署密鑰分發協議的相關信息設置為"已籤署"，否則，設置為"未籤署"。步驟102:安全應用伺服器根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的同一個密鑰分配給主叫終端和被叫終端；本步驟是利用端到端加密協商方式獲得相應的密鑰，即主叫終端和被叫終端在呼叫過程中協商生成密鑰的加密能力信息，安全應用伺服器根據雙方協商確定的加密能力信息生成密鑰，再將生成的密鑰分別發送給主叫終端和被叫終端。在實現時，該方法可以具體為bl、被叫終端接收來自主叫終端的呼叫請求消息，所述呼叫請求消息攜帶有主叫終端的加密能力信息；b2、被叫終端根據主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，再返回攜帶有生成密鑰的加密能力信息的呼叫響應消息；b3、主叫側安全應用伺服器根據呼叫響應消息中的加密能力信息生成密鑰並將生成的密鑰發送給主叫終端；M、主叫終端再向被叫終端發送呼叫相關消息，在發送所述呼叫相關消息的過程中，主叫側安全應用伺服器將生成的密鑰攜帶於所述呼叫相關消息發送給被叫終端。利用上述端到端加密協商方式後，主叫終端和被叫終端都可以獲取密鑰，在此後整個傳輸過程中，可以利用獲取的密鑰對媒體流進行加密傳輸。步驟103:安全應用伺服器根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的密鑰分配給自身所在一側的終端。本步驟是利用分段加密方式獲取相應的密鑰，即主叫側和被叫側分別生成各自的密鑰，其實現方法可以為cl、主叫側安全應用伺服器記錄來自主叫終端呼叫請求消息中的主叫終端加密能力信息；c2、被叫終端在接收到呼叫請求後，返回攜帶有自身加密能力信息的呼叫響應消息，被叫側安全應用伺服器從呼叫響應消息中獲取並記錄被叫終端的加密能力信息；c3、主叫側安全應用伺服器將根據主叫終端加密能力信息生成的密鑰發送給主叫終端，並下發給主叫側媒體流承栽設備；c4、被叫側安全應用伺服器將根據被叫終端加密能力信息生成的密鑰發送給被叫終端，並將生成的密鑰下發給被叫側媒體流承載設備。在利用分段加密協商的方式中，主叫終端、主叫側媒體流承栽設備、被叫側媒體流承載設備和被叫終端都獲取了密鑰，在此後的媒體流傳輸過程中，主叫終端和主叫側媒體流承載設備之間將傳輸經過加密的媒體流，被叫側媒體流承栽設備和被叫終端之間也將傳輸經過加密的媒體流，而主叫側媒體流承載設備和被叫側媒體流承栽設備之間將傳輸明文的媒體流。這裡所述分段加密方式獲取相應的密鑰的方法是在被叫側將加密業務作為基本業務的情況下的方法。如果被叫側將加密業務作為增值業務，則在被叫終端接收呼叫請求之前，該方法還可以進一步包括被叫側安全應用伺服器查詢事先設置的加密業務籤約信息，根據用戶標識判斷出被叫終端是否已經籤約，如果已經籤約，則繼續執行，即執行上述c2c4的步驟；否則，執行步驟X;所述步驟X為在被叫終端返回呼叫響應消息過程中，主叫側安全應用伺服器將根據主叫終端加密能力信息生成的密鑰發送給主叫終端，並下發給主叫側媒體流承栽設備。這裡，在步驟X中，由於只有主叫終端和主叫側4某體流獲取了密鑰，在此後的媒體流傳輸過程中，只有主叫側對媒體流進行加密，而被叫側對媒體流進行明文傳輸。上述是主叫側將加密作為基本業務的情況，如果主叫側將加密作為增值業務，並且在被叫側將加密業務作為基本業務的情況下，可以在步驟101檢查籤署分發密鑰協議之前，該方法進一步包括主叫側安全應用伺服器查詢事先設置的加密業務籤約信息，根據用戶標識判斷主叫終端是否已經籤約，如果已經籤約，則繼續執行步驟101;否則，執行步驟Y;所述步驟Y為yl、被叫終端接收來自主叫終端的呼叫請求消息，所述呼叫請求消息攜帶有主叫終端的加密能力信息；y2、被叫終端根據主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，返回攜帶有生成密鑰的加密能力信息的呼叫響應消自y3、被叫側安全應用伺服器根據呼叫響應消息中的加密能力信息生成密鑰，並將生成的密鑰發送給主叫終端；y4、主叫終端再向被叫終端返回呼叫相關消息，被叫側安全應用伺服器通過所述呼叫相關消息將生成的密鑰發送給^^皮叫終端。這裡，由於主叫終端和被叫終端都獲取了密鑰，在此後整個傳輸過程中，可以利用獲取的密鑰對i某體流進行加密傳輸。與主叫側將加密業務作為基本業務不同的是，這裡所迷的端到端加密所利用的密鑰是由被叫側安全應用伺服器生成的。當然，步驟yl所述被叫終端接收到呼叫響應消息之前，主叫側安全應用伺服器還可以先4艮據呼叫請求消息判斷出主叫終端所屬域與被叫終端所屬域已籤署密鑰分發協議，之後，呼叫請求消息才被發送給被叫終端。如果被叫側將加密業務作為增值業務，那麼，在步驟yl所述被叫終端接收到呼叫請求消息之前，該方法還可以包括被叫側安全應用伺服器查詢事先設置的加密業務籤約信息，根據用戶標識判斷出被叫終端已經籤約。如果判斷出被叫終端沒有籤約，也就是說，主叫側和被叫側都不支持加密業務，那麼，主叫終端和被叫終端將不會獲取密鑰，並將按照現有技術實現呼叫流程。不管主叫側將加密業務作為基本業務，還是作為增值業務，這裡所述的呼叫請求消息都是攜帶有加密能力信息的呼叫請求消息，即主叫終端主動要求進行加密。實際應用中，，主叫終端可以不支持加密或者不要求加密，發出的呼叫請求消息為不帶加密能力信息的呼叫請求消息。在這種情況下，就可以先判斷呼叫請求消息是否攜帶有加密能力信息，如果有，再繼續執行；如果沒有，則執行步驟Z;所述步驟Z為zl、被叫終端接收到呼叫請求消息後，返回攜帶有加密能力信息的呼叫響應消息；z2、被叫側安全應用伺服器從呼叫響應消息中獲得並記錄被叫終端的加密能力信息；z3、當主叫終端接收到呼叫響應消息後，再向被叫終端發送呼叫相關消息，在發送的過程中，被叫側安全應用伺服器將根據加密能力信息生成的密鑰通過呼叫相關消息發送給被叫終端，並下發給被叫側媒體流承載設備。由於只有被叫終端和被叫側媒體流承載設備獲取了密鑰，在此後的媒體流傳輸過程中，只有被叫側利用獲取的密鑰對媒體流進行加密傳輸，而主叫側對媒體流進行明文傳輸。這裡，由於主叫終端發送的是不包含加密能力信息的呼叫請求，還可以在所述被叫終端接收到呼叫請求消息之前，由被叫側安全應用伺服器將事先保存的加密能力信息插入呼叫請求消息；這樣，被叫終端返回呼叫響應消息之前，被叫終端就可以根據呼叫請求消息中的加密能力信息和自身加密能力信息，確定生成密鑰的加密能力信息，並將確定生成密鑰的加密能力信息添加到呼叫響應消息中。另外，這裡所述步驟Z是被叫側將加密業務作為基本業務的情況。如果將加密業務作為增值業務，被叫終端接收到呼叫請求消息之前，被叫側安全應用伺服器還可以先查詢事先設置的加密業務籤約信息，根據用戶標識判斷出被叫終端已經籤約。當然，如果判斷出被叫終端沒有籤約，則可以直接執行現有的呼叫流程，主叫終端和被叫終端都不會獲取密鑰。實際應用中，所述呼叫流程中主叫終端和被叫終端之間交互的消息可以包括獲取密鑰狀態標識，如果主叫終端/被叫終端沒有獲取密鑰，則將發送給被叫終端/主叫終端消息中的獲取密鑰狀態標識設置為未獲取密鑰標識；否則，設置為已獲取密鑰標識。通過獲取密鑰狀態標識可以使呼叫雙方將自身獲取密鑰的情況通知給對方。實際應用中，本發明所述的安全應用伺服器可以為IP多々某體子系統的應用伺服器(IMS-AS)，可以為呼叫會話控制功能實體(CSCF)中的功能模塊，也可以為第三方伺服器。如果安全應用伺服器為IMS-AS,呼叫請求消息是主叫終端經過主叫側IMS-AS和被叫側IMS-AS發送給被叫終端的，那麼路由呼叫請求消息的方法具體為主叫終端將呼叫請求消息發送給主叫側S-CSCF;主叫側S-CSCF根據事先獲得的過濾準則，對接收到的呼叫請求消息進行過濾處理，並將攜帶有加密能力信息的呼叫請求消息轉發給主叫側安全應用伺服器；主叫側安全應通過主叫側S-CSCF發送給被叫側S-CSCF;被叫側S-CSCF根據事先獲得的過濾準則，對接收到的呼叫請求消息進行過濾處理，並將攜帶有加密能力信息的呼叫請求消息轉發給被叫側安全應用伺服器；被叫側安全應用伺服器再將呼叫請求消息轉發給被叫終端。為了更好地說明本發明方案，下面用較佳實施例進行詳細描述。方法實施例一本實施例中，主叫側和被叫側都將加密業務作為基本業務，並且，主叫側所屬運營商和被叫側所屬運營商之間已經籤署了分發密鑰協議；所述安全應用伺服器為IMS-AS，分為主叫側IMS-AS和被叫側IMS-AS，並由主叫側IMS-AS生成密鑰。圖2是本實施例的消息流示意圖。如圖2所示，本實施例包括以下步驟步驟201:主叫終端發起呼叫，將呼叫請求消息發送給主叫側S-CSCF;這裡所述的呼叫請求消息就是會話初始協議(SIP)中的INVITE消息，可以採用四種方法將主叫終端的加密能力信息承栽在INVITE消息中第一種方法是承載在INVITE消息的會話描述協議(SDP)中；第二種方法是承載在INVITE消息中SIP主叫屬性接收協商(Accept-contact)頭域中;第三種方法是承載在INVITE消息中SIP的擴展協商域中；第四種方法是承載在INVITE消息中徵求意見稿(RFC4568)標準所定義的欄位中。這裡所述的加密能力信息也可以稱為加密能力聲明，可以包括SRTP支持、加密算法的支持、密鑰長度的支持等信息。前三種承載方式可以參見本申請人:另一專利申請，此處不再贅述。對於第四種承載方式，可以將加密能力信息承載到SDP的a欄位中。另外，呼叫請求消息中還可以攜帶關於加密的安全前提，安全前提中可以包括指定加密方式的標識。在這種情況下，第四種承載方式的格式可以為m=video51372RTP/SAVP31a=cuir:sece2enonea=des:secmandatorye2esendrecva=crypt:1AES—CM_128_HMAC—SHA1—80inline:a=crypt:2AES—CM—128HMAC—SHA1—32inline:m=audio49170RTP/SAVP0a=curr:sec6之cnonea=des:secmandatorye2esendrecva=crypto:lAES—CM—128—HMAC_SHA1_32inline:a=crypto:2AES_CM—128_HMAC—SHA1—80inline:這裡包括關於視頻流和音頻流的兩個加密能力聲明和安全前提，以關於視頻流的為例，其中，"a=curr:sece2enone，，和"a:des:secmandatorye2esendrecv"就是安全前提，表示主叫終端期望強制的端到端接收和發送兩個方面的媒體流加密，同時指出當前主叫終端還沒有實現與媒體流加密有關的前提。另外，"inline"欄位表示用於承載密鑰。如果主叫終端還沒有獲取密鑰，"inline"欄位應該為空；如果網絡側生成了密鑰並需要發送給主叫終端，那麼，就可以將生成的密鑰承栽於返回主叫終端的消息中的"inline"欄位中，主叫終端可以從"inline"欄位中獲取密鑰。實際應用中，由於存在被叫終端可能不支持加密的情況，為了保證呼叫能夠成功，也可以在呼叫請求消息中包括不含加密信息的聲明，即在上述聲明後增力o以下兩個聲明m=video51372RTP/AVP31m-audio49170RTP/AVP0這樣，如果對方不支持加密，則可以按照現有技術完成呼叫過程。步驟202~步驟203:主叫側S-CSCF根據事先獲得的過濾準則，對接收到的呼叫請求消息進行過濾處理，並將攜帶有加密能力信息的呼叫請求消息轉發給主叫側IMS-AS。本實施例中，由於主叫側將加密業務作為基本業務，那麼這裡所述的過濾準則可以是事先為用戶提供的預設過濾準則，其格式可以如表一所示優先級觸發點SIP方法證ITESIP消息頭Require:preconditiona=cryptom=RTP/SAVPM情形源端(Originating)地址主叫側IMS-AS的地址表一這樣，就可以將呼叫請求消息觸發給主叫側IMS-AS處理，並且，在此後的呼叫過程中，主叫側IMS-AS將處於呼叫的信令鏈路中，即所有與呼叫相關的消息都將經過主叫側IMS-AS。步驟204~步驟206:主叫側IMS-AS判斷出主叫終端所屬域與被叫終端所屬域已籤署密鑰分發協議，並將呼叫請求消息通過主叫側S-CSCF發送給被叫側S-CSCF。如果呼叫請求消息中還攜帶有包括安全前提，並在安全前提中包括端到端加密標識，主叫側IMS-AS根據呼叫請求就可以判斷出這裡一個要求端到端加密的呼叫請求消息。另外，由於本實施例由主叫側IMS-AS生成密鑰，為了將生成密鑰的情況通知給被叫側IMS-AS,主叫側IMS-AS還可以將主叫側生成密鑰標識插入呼叫請求消息。步驟207~步驟210:被叫側S-CSCF根據事先獲得的過濾準則，對接收到的呼叫請求消息進行過濾處理，並將攜帶有加密能力信息的呼叫請求消息轉發給被叫側IMS-AS,再通過被叫側S-CSCF轉發給被叫終端。與主叫側相似，本實施例中，被叫側也是將加密業務作為基本業務，這裡所述的過濾準則可以是事先為用戶提供的預設過濾準則，其格式如表二所示tableseeoriginaldocumentpage18表二這樣，就可以將呼叫請求消息觸發給被叫側IMS-AS處理，並且，在此後的呼叫過程中，被叫側IMS-AS將處於呼叫的信令鏈路中，即所有與呼叫相關的消息都將經過被叫側IMS-AS。如果呼叫請求消息包括加密方式和生成密鑰側標識，被叫側S-CSCF從呼叫請求消息就可以判斷出該呼叫要求端到端加密方式，並且由主叫側IMS-AS生成密鑰。步驟211~步驟216:被叫終端根據呼叫請求消息中主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，再向主叫側IMS-AS:E4回攜帶有生成密鑰的加密能力信息的呼叫響應消息。本實施例中，淨皮叫終端可以返回m=video31337RTP/SAVP31a=curr:sece2enonea=des:secmandatorye2esendrecva=conf:sece2esendrecva=crypto:lAES_CM—128—HMAC—SHA1—80CALLER-ALLOC-KEYinline:m=audio31399RTP/SAVP0formulaseeoriginaldocumentpage19在呼叫請求消息中包括有加密能力信息的和沒有加密能力信息的兩種呼叫請求的情況下，如果被叫終端不支持加密，將返回4xx錯誤消息，或者針對沒有加密能力信息的呼叫請求返回呼叫響應消息，即實現普通的呼叫。步驟217-步驟220:主叫側IMS-AS根據呼叫響應消息中的加密能力信息生成密鑰，並將生成的密鑰返回給主叫終端。如果消息中包括安全前提，當主叫終端從呼叫響應消息中獲取密鑰後，還可以更改安全前提，同時向被叫終端發送確認信息。比如formulaseeoriginaldocumentpage19其中，第二行和第七行粗體字部分就是更改後的前提。步驟221-步驟229:主叫終端向被叫終端發送呼叫相關消息，在發送的過程中，主叫側IMS-AS將生成的密鑰攜帶於所述呼叫相關消息發送給被叫終端。這裡所迷呼叫相關消息可以為確認消息(PRACK)或更新信息消息(UPDATE)等消息。本實施例中，主叫側IMS-AS可以由以下方式將密鑰攜帶於消息中，即承載在inliae欄位中。比如m=video51372RTP/SAVP31a=curr:sccc2cssndrecva=des:secmandatorye2esendrecva=crypto:lAES_CM—128_HMAC_SHA1—80CALLER曙ALLOC-KEYinline:dORmd旭cmVCspeEc3QGZiNWpVLFJhQXlcfflAwJSojm=audi49170RTP/SAVP0a=curr:sece之esendrecva=des:secmandatorye2esendrecva=c(mf:sece2esendrecva=crypto:lAES—CM_128_HMAC_SHA1_32CALLER-ALLOC-KEYinline:NzB4dlBINUAvLEw6UzF3WSJ+PSdFcGdUJShpXlZj其中，第五行和第十一行粗體就是攜帶的密鑰。當然，主叫終端和被叫終端之間還需要完成呼叫的其他過程，比如當接收到PRACK消息後，被叫終端還需要向主叫終端返回200OK消息，呼叫流程的具體情況可以參見現有技術，此處不再贅述。本實施例中的安全應用伺服器是以IMS-AS為例進行說明的，實際應用中，安全應用伺服器也可以是S-CSCF中的功能模塊，或者為第三方伺服器。在這種情況下，呼叫信令鏈路可以與現有技術中的信令鏈路相同，實現端到端加密的方法與本實施例相似，其區別在於如果是S-CSCF中的功能模塊，檢查主叫終端所屬域和被叫終端所屬域是否籤署協議、將主叫側密鑰生成側標識插入呼叫請求消息、生成密鑰等都可以直接由主叫側S-CSCF完成；如果是第三方伺服器，第三方伺服器可以只負責生成密鑰，檢查主叫終端所屬域和被叫終端所屬域是否籤署協議、將主叫側密鑰生成側標識插入呼叫請求消息等可以由S-CSCF完成；或者，檢查主叫終端所屬域和被叫終端所屬域是否籤署協議、將主叫側密鑰生成側標識插入呼叫請求消息、生成密鑰等全部由第三方伺服器完成，不管是哪種方法，都需要S-CSCF和第三方伺服器之間確定交互的協議，所迷交互的協議可以由應用本發明方案的用戶自行確定。方法實施例二本實施例中，主叫側和被叫側都將加密業務作為基本業務，但主叫終端所屬域和被叫終端所屬域之間沒有籤署密鑰分發協議；本實施例中，安全應用伺服器為S-CSCF中的功能模塊，即安全應用單元，但為了更好地說明流程，仍然將S-CSCF和安全應用單元分開敘述。圖3是本實施例的消息流示意圖。如圖3所示，本實施例包括以下步驟步驟301~步驟303與實施例一的步驟201~步驟203相似，其區別僅僅在於，主叫側S-CSCF將呼叫請求消息發送給自身的安全應用單元處理。步驟304~步驟306:主叫側安全應用單元判斷出主叫終端所屬域與尋皮叫終端所屬域沒有籤署密鑰分發協議，記錄下呼叫請求消息中的主叫終端的加密能力信息後，再將呼叫請求消息發送給被叫側S-CSCF。與實施例一相似，如果呼叫請求消息中還攜帶有包括安全前提，並在安全前提中包括端到端加密標識，主叫側安全應用單元根據呼叫請求就可以判斷出這裡一個要求端到端加密的呼叫請求消息。但由於主叫終端所屬域與被叫終端所屬域沒有籤署密鑰分發協議，主叫側安全應用單元則可以確定採用分段加密的方式。為了將加密方式通知給被叫側，主叫側安全應用單元還可以將端到端加密標識更改為分萃殳加密標識。此後，；故叫側就可以才艮據該標識確定該呼叫請求要求進行分段加密。如果不需要被叫終端的用戶獲取加密方式已經被更改過，被叫側還可以將分段加密標識更改為端到端加密標識之後再發送給被叫終端。當然，這種情況下，當被叫終端返回消息時，也需要將其中的端到端加密標識又重新更改為分,殳加密標識。實際應用中，在確定為分段加密方式後，如果終端具備解析標誌能力，還可以提示用戶此次會話不能完全保證通話的安全性。另外，由於進行分段加密，主叫側和被叫側雙方無需知道對方的加密能力信息，可以在確定採用分段加密的情況下，將呼叫請求消息中的與加密相關的信息刪除。如果網絡側採用哪種加密方式的情況並不需要報告給主叫終端，那麼，在返回消息給主叫終端時，還可以將事先更改過的加密方式重新恢復為端到端加密。307-步稞310與實施例一中的步驟207-步驟210相似，其區別僅僅在於，被叫側S-CSCF將呼叫請求消息發送給自身的安全應用單元處理。步驟311步驟314:被叫終端在接收到呼叫請求消息後，返回攜帶有自身加密能力信息的呼叫響應消息，被叫側安全應用伺服器從呼叫響應消息中獲取並記錄被叫終端的加密能力信息。步驟315~步驟321:被叫側S-CSCF繼續將呼叫響應消息發送給主叫終端，在發送的過程中，主叫側安全應用單元將根據主叫終端加密能力信息生成的密鑰攜帶於呼叫響應消息中發送給主叫終端，並下發給主叫側媒體流承載設備。本實施例中，主叫側安全應用單元是在步驟317中根據步驟304記錄的主叫終端加密能力信息生成密鑰的，但在實際應用中，只要主叫側安全應用單元獲得了主叫終端得加密能力信息，任何時候都可以生成密鑰，並不一定在步驟317生成。另外，本實施例中，所述媒體流承載設備可以為MP。當主叫側安全應用單元需要將生成的密鑰下發給MP時，該方法為主叫側安全應用單元通過主叫側S-CSCF將攜帶有密鑰的呼叫響應消息發送給主叫側P-CSCF，主叫側P-CSCF再將攜帶有密鑰的才艮文發送給主叫側MP。實際應用中，當主叫側P-CSCF需要將密鑰下發給主叫側MP時，可以通過資源和接入控制子系統(RACS)將密鑰下發給主叫側MP。比如主叫側P-CSCF發起資源預留過程，在資源預留過程中，主叫側P-CSCF將生成的密鑰發送給主叫側RACS，主叫側RACS再將密鑰發送給主叫側MP。當然，主叫側P-CSCF也可以通過一個獨立的下發密鑰的過程將密鑰發送給主叫側MP,只要能夠將密鑰發送給主叫MP即可。步驟322-步驟328:主叫終端向被叫終端發送呼叫相關消息，並在發送呼叫相關消息的過程中，被叫側安全應用單元將根據被叫終端加密能力信息生成的密鑰攜帶於呼叫相關消息中發送給被叫終端，並下發給被叫側媒體流承栽設備。這裡，所述呼叫相關消息可以為任何從主叫終端發送給被叫終端的消息，比如UPDATE消息、PRACK消息等。與主叫側生成密鑰相似，本實施例中，被叫側安全應用單元是在步驟323時，根據步驟313獲取的被叫終端的加密能力信息生成密鑰的。實際應用中，只要被叫側安全應用單元獲得的被叫終端的加密能力信息，在之後的任何是否生成密鑰都可以，並不一定在步驟324中生成。本實施例所述被叫側將密鑰下發給被叫側媒體流承載設備的方法與主叫側下發密鑰給主叫側媒體流承載設備的方法相似，此處不再贅述。另外，本實施例是以安全應用單元為S-CSCF中的功能單元為例敘述，如果是P-CSCF中的功能單元，其方法與本實施例相似，只是在P-CSCF中生成密鑰後，由P-CSCF將密鑰發送給終端，並直接下發給媒體流承載設備即可，至於具體流程此處則不再詳細描述。方法實施三本實施例衝，主叫側將加密業務作為基本業務，而被叫側將加密作為增值業務，並且被叫終端未籤約該加密業務，主叫終端所屬域與被叫終端所屬域之間沒有籤署分發密鑰協議；本實施例中，安全應用伺服器為IMS-AS。圖4是本實施例的消息流示意圖。如圖4所示，本實施例包括以下步驟步驟401~步驟410與實施例二中步驟301~步驟310相似，其區別在於，當被叫側IMS-AS接收到呼叫請求消息時，還將查詢事先設置的加密業務籤約信息，根據用戶標識判斷出被叫終端沒有籤約加密業務。由於被叫終端沒有籤約加密業務，被叫側將不會為被叫終端生成密鑰。在這種情況下，被叫側IMS-AS也可以將自身從信令鏈路中刪除，此後的呼叫流程中的消息將不再經過被叫側IMS-AS;或者被叫側IMS-AS也可以不將自身從信令鏈路中刪除，但只是轉發消息的作用。步驟411-步驟417:被叫終端向主叫終端返回呼叫響應消息，在返回呼叫響應消息過程中，主叫側安全應用伺服器將根據主叫終端加密能力信息生成的密鑰發送給主叫終端，並下發給主叫側媒體流承載設備。此後主叫終端和被叫終端還需要完成呼叫流程中的其他部分，但被叫側不會生成密鑰，也不會將密鑰發送給被叫終端和被叫側媒體流承載設備，被叫側部分的呼叫流程可以與現有技術相同。至於主叫側如何將密鑰下發給媒體流承載設備與實施例二相同，此處也不再贅述。當呼叫流程結束後，只有主叫終端和主叫側媒體流承載設備獲得了密鑰，媒體流在主叫終端和主叫側媒體流承載設備是加密傳輸的，而在被叫側是明文傳輸。方法實施例四本實施例中，主叫側和被叫側都將加密業務作為增值業務，主叫終端沒有籤約加密業務，而被叫終端籤約了加密業務；主叫終端所屬域和被叫終端所屬域之間已經籤署了密鑰分發協議。圖5是本實施例的消息流示意圖。如圖5所示，本實施例包括以下步驟步驟501~步驟503與實施例一中的步驟201~步驟203相同，此處不再詳細描述。步驟504~步驟506:主叫側IMS-AS查詢事先設置的加密業務籤約信息，根據用戶標識判斷出主叫終端沒有籤約，判斷出主叫終端所屬域與被叫終端所屬域已籤署密鑰分發協議，再並將呼叫請求消息通過主叫側S-CSCF發送給^皮叫側S-CSCF。與實施例一相似，如果呼叫請求消息中攜帶有安全前提，所屬安全前提中包括端到端加密標識，主叫側IMS-AS根據呼叫請求就可以判斷出這是一個要求端到端加密的呼叫請求消息。由於主叫終端沒有籤約業務，主叫側將不會為主叫終端生成密鑰，為了將此情況通知給被叫側，主叫側IMS-AS可以將#_叫側生成密鑰標識插入呼叫請求消息。步驟507~步驟510與實施例一中的步驟207~步驟210相似，其區別在於，當被叫側IMS-AS接收到呼叫請求消息後，將查詢事先設置的加密業務籤約信息，根據用戶標識判斷出被叫終端已經籤約。當然，如果呼叫請求消息還包括安全前提等信息，主叫側IMS-AS還可以根據呼叫請求消息確定加密方式為端到端加密，並且密鑰由被叫側安全應用伺服器生成。實際應用中，如果被叫側IMS-AS判斷出被叫終端沒有籤約加密業務，則可以將自身從鏈路中刪除，並將無密鑰生成標識插入消息中。此後，當主叫側IMS-AS從呼叫響應消息中獲取無密鑰生成標識，就可以也將自身從信令鏈路中刪除。步驟511~步驟513:被叫終端根據呼叫請求消息中主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，再向被叫側IMS-AS返回攜帶有生成密鑰的加密能力信息的呼叫響應消息。步驟514:被叫側IMS-AS根據呼叫響應消息中的加密能力信息生成密鑰，並將生成的密鑰攜帶於呼叫響應消息中。步驟515-步驟520與實施例一中步驟214~步驟220相似，其區別在於，當主叫側IMS-AS接收到呼叫響應消息時，不會再生成密鑰，而是直接轉發出去即可。步驟521~步驟529與實施例一步驟221~步驟229相似，其區別在於，當主叫側IMS-AS接收到呼叫相關消息時，將不會將密鑰攜帶於呼叫相關消息中，而是後續過程中，由被叫側將密鑰攜帶於呼叫相關消息中發送給被叫終端。方法實施例五本實施例中，主叫終端發起的呼叫請求消息不攜帶加密能力信息，即不要求加密；實際應用中，終端可以為用戶提供"加密，，、"不加密，，、"自動協商是否加密"等選項，終端根據用戶的選擇決定是否生成攜帶有加密聲明的呼叫請求消息。本實施例中，被叫側將加密業務作為增值業務，並且被叫終端已經籤約該加密業務；本實施例中，安全應用伺服器為S-CSCF中的一個功能單元，並且為了敘迷簡便，在示意圖不單獨表示安全應用伺服器。圖6是本實施例的消息流示意圖。如圖6所示，本實施例包括以下步驟步驟601~步驟603:主叫終端將呼叫請求消息發送給主叫側S-CSCF,主叫側S-CSCF直接將呼叫請求消息轉發給被叫側S-CSCF;步驟604~步驟606:#1叫側S-CSCF將加密能力信息插入呼叫請求消息，再轉發給被叫終端。步驟607:被叫終端根據呼叫請求消息中的加密能力信息和自身加密能力信息，確定生成密鑰的加密能力信息，並將確定生成密鑰的加密能力信息添加到呼叫響應消息中。步驟608~步驟609:被叫終端將呼叫請求消息返回給被叫側S-CSCF，被叫側S-CSCF中的安全應用單元根據呼叫響應消息中的加密能力信息生成密鑰。步驟610~步驟612:被叫側S-CSCF繼續向主叫終端返回呼叫響應消息。實際應用中，被叫側S-CSCF還可以將之前插入的加密能力信息刪除，向主叫終端返回的是一條普通的呼叫響應消息。步驟613-步驟主叫終端向被叫終端發送呼叫相關消息，在發送的過程中，被叫側S-CSCF將生成的密鑰攜帶於呼叫相關消息中發送給被叫終端，並下發給媒體流承載設備。針對本發明提出的方法，本發明還提出一種多媒體子系統。圖7是本發明所述的系統基本結構示意圖，該系統至少包括主叫終端701、安全應用伺服器702、被叫終端703。其中，所述安全應用伺服器702用於根據主叫終端所屬域與被叫終端所屬域的籤約情況確定加密方式，根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的密鑰發送給終端。另夕卜，本發明所述的安全應用伺服器702可以為IMS-AS,或者為CSCF的功能模塊，或者為第三方伺服器。系統實施例一圖8是本發明系統實施例一的基本結構圖。如圖8所示，由於呼叫過程中同時涉及主叫側和被叫側，安全應用伺服器702可以為主叫側安全應用伺服器和被叫側安全應用伺服器，本實施例還包括主叫終端701、主叫側S-CSCF704、被叫側S-CSCF705、被叫終端703。其中，主叫終端701用於發起呼叫，並從呼叫流程中獲取從主叫側安全應用伺服器或被叫側安全應用伺服器返回的密鑰；安全應用伺服器702生成密鑰並將密鑰發送給終端；主叫側S-CSCF704和被叫側S-CSCF轉發呼叫流程中的消息，並將攜帶有加密能力信息的呼叫請求消息發送給對應的安全應用伺服器。實際應用中，系統中還包括主叫側P-CSCF706、被叫側P-CSCF707、主叫側媒體流承載設備708、被叫側媒體流承載設備709。其中，主叫側P-CSCF706用於轉發呼叫消息，並將獲得的密鑰發送給主叫側媒體流承載設備708;被叫側P-CSCF706用於轉發呼叫消息，並將獲得的密鑰發送給被叫側媒體流承載設備709。實際應用中，安全應用伺服器702可以為S-CSCF中的功能模塊，或者為P-CSCF中的功能模塊，或者為IMS-AS，或者為第三方伺服器。當然，圖8僅僅是一個系統基本結構圖，每一個實體的功能與終端獲取密鑰的方式相關，此處不再贅述。本發明是以含有IMS的網絡，並且在IMS網絡中信令鏈路可以提供安全保障的情況為例進行說明的。實際應用中，還可以將本發明方法應用於其他類型的網絡中，如基於軟交換的下一代網絡，其方法與本發明類似，此處不再——列舉。應用本發明方案，主叫終端和被叫終端自身不生成密鑰，而是由安全應用伺服器生成密鑰，無需進行時鐘同步，也無需PKI體系的支持，可以大大降低媒體流密鑰協商的複雜度，便於媒體流加密業務的推廣。進一步地，如果採用端到端加密，可以從安全應用伺服器中獲取密鑰，從而滿足合法監聽的實際需求；如果採用分段加密，由於主叫側媒體流承載設備和被叫側媒體流承栽設備之間採用明文傳輸，也可以滿足合法監聽的實際需求。綜上所述，以上僅為本發明的較佳實施例而已，並非用於限定本發明的保護範圍。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。權利要求1.一種分配媒體流密鑰的方法，其特徵在於，預先設置生成密鑰的安全應用伺服器，當主叫終端發起呼叫時，該方法包括A、安全應用伺服器根據呼叫請求消息判斷主叫終端所屬域與被叫終端所屬域是否已籤署密鑰分發協議，如果已經籤署，執行步驟B後退出本流程；否則執行步驟C；B、安全應用伺服器根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的同一個密鑰分配給主叫終端和被叫終端；C、安全應用伺服器根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的密鑰分配給自身所在一側的終端。2、根據權利要求1所述的方法，其特徵在於，步驟B所述安全應用伺服器為主叫側安全應用伺服器，所述步驟B具體為bl、被叫終端接收主叫終端的呼叫請求消息，所述呼叫請求消息攜帶有主叫終端的加密能力信息；b2、被叫終端根據主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，再返回攜帶有生成密鑰的加密能力信息的呼叫響應消息；b3、主叫側安全應用伺服器根據呼叫響應消息中的加密能力信息生成密鑰，並將生成的密鑰發送給主叫終端；b4、主叫終端再向被叫終端發送呼叫相關消息，主叫側安全應用伺服器將生成的密鑰攜帶於所述呼叫相關消息發送給^皮叫終端。3、根據權利要求2所述的方法，其特徵在於，所述呼叫請求消息中攜帶有端到端加密標識，在步驟bl所述被叫終端接收到呼叫請求消息之前，該方法進一步包括主叫側安全應用伺服器將主叫側生成密鑰標識攜帶於呼叫請求消息中，被叫側安全應用伺服器才艮據所述呼叫請求消息確定加密方式為端到端加密，並確定密鑰由主叫側安全應用伺服器生成。4、根據權利要求1所述的方法，其特徵在於，步驟C所述安全應用伺服器為主叫側安全應用伺服器和被叫側安全應用伺服器，所述步驟C具體為c1、主叫側安全應用伺服器記錄來自主叫終端呼叫請求消息中的主叫終端加密能力信息；c2、被叫終端在接收到呼叫請求後，返回攜帶有自身加密能力信息的呼叫響應消息，被叫側安全應用伺服器從呼叫響應消息中獲取並記錄被叫終端的加密能力信息；c3、主叫側安全應用伺服器將根據主叫終端加密能力信息生成的密鑰發送給主叫終端，並下發給主叫側媒體流承栽設備；c4、被叫側安全應用伺服器將根據被叫終端加密能力信息生成的密鑰發送給被叫終端，並將生成的密鑰下發給被叫側媒體流承載設備。5、根據權利要求4所述的方法，其特徵在於，所述媒體流承載設備為媒體代理MP,步驟c3所述主叫側安全應用伺服器將生成的密鑰下發給主叫側MP的方法為主叫側安全應用伺服器將生成的密鑰通過主叫側呼叫會話控制功能實體CSCF發送給主叫側MP;步驟c4所述被叫側安全應用伺服器將密鑰下發給被叫側MP的方法為被叫側安全應用伺服器將生成的密鑰通過被叫側CSCF將密鑰發送給被叫側MP。6、根據權利要求4所述的方法，其特徵在於，所述被叫終端接收到呼叫請求之前，該方法進一步包括被叫側安全應用伺服器查詢事先設置的加密業務籤約信息，根據用戶標識判斷出被叫終端是否已經籤約，如果已經籤約，則繼續執行；否則，執行步驟X;所述步驟X具體為在淨皮叫終端返回呼叫響應消息過程中，主叫側安全應用伺服器將根據主叫終端加密能力信息生成的密鑰發送給主叫終端，並下發給主叫側媒體流承載設備。7、根據權利要求4所述的方法，其特徵在於，所述呼叫請求消息攜帶有端到端加密標識，步驟cl進一步包括主叫側安全應用伺服器將端到端加密標識更改為分段加密標識；步驟c2所述被叫終端接收呼叫請求之前，該方法進一步包括被叫側安全應用伺服器才艮據呼叫請求消息確定加密方式為分段加密。8、根據權利要求7所述的方法，其特徵在於，所述呼叫響應消息攜帶有分段加密標識，所述步驟c3進一步包括主叫側安全應用伺服器將分段加密標識恢復為端到端加密標識。9、根據權利要求1所述的方法，其特徵在於，所述步驟A進一步包括主叫側安全應用伺服器查詢事先設置的加密業務籤約信息，根據用戶標識判斷主叫終端是否已經籤約，如果已經籤約，則繼續執行；否則，執行步驟Y;所述步驟Y為yl、被叫終端接收來自主叫終端的呼叫請求消息，所述呼叫請求消息攜帶有主叫終端的加密能力信息；y2、被叫終端根據主叫終端的加密能力信息和自身的加密能力信息，確定生成密鑰的加密能力信息，返回攜帶有生成密鑰的加密能力信息的呼叫響應消息；y3、被叫側安全應用伺服器根據呼叫響應消息中的加密能力信息生成密鑰，並將生成的密鑰發送給主叫終端；y4、主叫終端再向被叫終端返回呼叫相關消息，被叫側安全應用伺服器通過所迷呼叫相關消息將生成的密鑰發送給被叫終端。10、根據權利要求9所述的方法，其特徵在於，步驟yl所述被叫終端接收到呼叫響應消息之前，該方法進一步包括主叫側安全應用伺服器根據呼叫請求消息判斷出主叫終端所屬域與被叫終端所屬域已籤署密鑰分發協議。11、根據權利要求9所述的方法，其特徵在於，所述呼叫請求消息攜帶有端到端加密標識，步驟yl所述被叫終端接收到呼叫請求消息之前，該方法進一步包括主叫側安全應用伺服器將被叫側生成密鑰標識攜帶於呼叫請求消息中，被叫側安全應用Jil務器根據呼叫請求消息確定加密方式為端到端加密，並且密鑰由#皮叫側安全應用伺服器生成。12、根據權利要求9所述的方法，其特徵在於，步驟yl所述被叫終端接收到呼叫請求消息之前，該方法進一步包括被叫側安全應用伺服器查詢事先設置的加密業務籤約信息，根據用戶標識判斷出被叫終端已經籤約。13、根據權利要求9所述的方法，其特徵在於，所述主叫側安全應用伺服器查詢加密業務籤約信息之前，該方法進一步包括主叫側安全應用伺服器判斷呼叫請求消息是否包含加密能力信息，如杲有，則繼續執行；否則，執行步驟Z;所述步驟Z為zl、被叫終端接收到呼叫請求消息後，返回攜帶有加密能力信息的呼叫響應消息；z2、被叫側安全應用伺服器從呼叫響應消息中獲得並記錄被叫終端的加密能力信息；z3、當主叫終端接收到呼叫響應消息後，再向被叫終端發送呼叫相關消息，在發送的過程中，被叫側安全應用伺服器將根據加密能力信息生成的密鑰通過呼叫相關消息發送給被叫終端，並下發給被叫側媒體流承載設備。14、根據權利要求13所述的方法，其特徵在於，步驟zl所述被叫終端接收到呼叫請求消息之前，該方法進一步包括被叫側安全應用伺服器將加密能力信息插入呼叫請求消息；步驟zl所述被叫終端返回呼叫響應消息之前，該方法進一步包括被叫終端根據呼叫請求消息中的加密能力信息和自身加密能力信息，確定生成密鑰的加密能力信息，並將確定生成密鑰的加密能力信息添加到呼叫響應消息中。15、根據權利要求13所述的方法，其特徵在於，步驟zl被叫終端接收到呼叫請求消息之前，該方法進一步包括被叫側安全應用伺服器查詢事先設置的加密業務籤約信息，根據用戶標識判斷出被叫終端已經籤約。16、根據權利要求1所述的方法，其特徵在於，所述呼叫流程中主叫終端和被叫終端之間交互的消息包括獲取密鑰狀態標識，該方法進一步包括如果主叫終端/被叫終端沒有獲取密鑰，則將發送給被叫終端/主叫終端消息中的獲取密鑰狀態標識設置為未獲取密鑰標識；否則，設置為已獲取密鑰標識。17、一種多々某體子系統，至少包括主叫終端和淨皮叫終端，其特徵在於，該系糹充還包4舌安全應用伺服器，用於根據主叫終端所屬域與被叫終端所屬域的籤約情況確定加密方式，才艮據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的密鑰發送給終端。18、根據權利要求17所述的系統，其特徵在於，所述安全應用伺服器為多媒體子系統應用伺服器IMS-AS，或者為呼叫會話控制功能實體CSCF的功能模塊，或者為第三方伺服器。全文摘要本發明提供一種分配媒體流密鑰的方法和多媒體子系統，具體為預先設置生成密鑰的安全應用伺服器，當主叫終端發起呼叫時，安全應用伺服器根據呼叫請求消息判斷主叫終端所屬域與被叫終端所屬域是否已籤署密鑰分發協議，如果已經籤署，安全應用伺服器根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的同一個密鑰分配給主叫終端和被叫終端；如果沒有籤署，安全應用伺服器根據在呼叫過程中獲得的加密能力信息生成密鑰，並將生成的密鑰分配給自身所在一側的終端。應用本發明方案，主叫終端和被叫終端自身並不生成密鑰，而是由安全應用伺服器生成密鑰，可以大大降低端到端媒體流密鑰協商的複雜度，便於媒體流加密業務的推廣。文檔編號H04L9/08GK101232368SQ20071000271公開日2008年7月30日申請日期2007年1月23日優先權日2007年1月23日發明者濤孔,愷孫,高江海,靜黎申請人:華為技術有限公司