視頻監控系統中一種基于HTTP摘要安全認證設計

王永建 張 健 鐵小輝 楊建華 郭廣濤

(中國通信建設集團設計院有限公司 北京 100079)

視頻監控系統中一種基于HTTP摘要安全認證設計

王永建 張 健 鐵小輝 楊建華 郭廣濤

(中國通信建設集團設計院有限公司 北京 100079)

(kingselfme@sina.com)

在平安城市的建設中，視頻監控系統中客戶端的安全認證非常關鍵.為了彌補SIP的不足，設計了一種基于HTTP摘要的認證方案.首先簡析了SIP與HTTP協議；設計了視頻監控系統整體結構，定義了各主要組成部件的功能.然后設計了登錄注銷，獲取設備屬性列表.最后設計了認證流程、AG的質詢消息頭、MC的應答消息頭、Response參數等實現方案.該設計思路對提高SIP協議的安全性具有一定借鑒意義.

SIP；SDP；HTTP摘要；質詢；應答

為了構建和諧社會，建設平安中國，2012年6月1日，公安部發布了《安全防范視頻監控聯網系統信息傳輸、交換、控制技術要求》(GBT 28181—2011)等相關文件，正式啟動了國家平安城市的建設工作，視頻監控系統是建設主體[1].

作為一種安防系統，視頻監控系統自身的信息安全尤為重要.根據CompTIA(美國計算機行業協會)發布的安全調查報告顯示，信息安全事故中，約63%的事故是由于內部人員安全意識匱乏和安全技能低下的人為錯誤所致，只有8%的信息安全事故是因技術原因而引起的[2].

隨著移動互聯網、云計算、大數據、智能終端、Web等技術的發展，瀏覽器服務器(browserserver, BS)服務模式以其開發簡捷、部署便捷、消耗資源少、維護成本低等特點而廣泛應用，以APP為代表的Web客戶端是典型代表，并在視頻監控系統中逐步推廣[3].

客戶端作為用戶主要的登錄入口和操作渠道，是信息安全事故的高發區域，因此視頻監控系統中客戶端的安全認證非常關鍵.本文考慮會話初始協議(session initiation protocol, SIP)自身安全性缺陷，借助超文本傳輸協議(hypertext transfer protocol, HTTP)，設計了一種視頻監控客戶端安全認證方案.

1 相關協議分析

1.1 SIP協議

SIP是基于HTTP和簡單郵件傳送協議(simple mail transfer protocol, SMTP)的信令協議，屬于一個應用層的控制協議，基于請求響應的事務處理模型，使用消息方式完成用戶會話的建立和管理[4].如圖1所示：

圖1 SIP,HTTP協議在網絡體系結構中的位置

SIP支持名字映射和重定向服務，將原來請求的地址映射為新地址，只進行重定向，并不參與事務的處理.SIP非常適用于作為客戶唯一的外部標志，而與實際的網絡位置無關.

SIP消息分為2類：SIP請求和SIP響應；其中請求消息由客戶機發往服務器，響應消息由服務器發往客戶機[5].請求消息和響應消息格式由一個起始行、若干個頭字段以及一個可選的消息體組成[6].請求和響應消息的基本格式如下：

SIP消息=起始行

*消息頭部(1個或多個頭部)

CRLF(空行)

[消息體]

請求消息的起始行為請求行：

Request-Line=Method SP Request-URI SP SIP-Version CRLF[7].

響應消息的起始行為狀態行：

Status-Line=SIP-Version SP Status-Code SP Reason-Phrase CRLF[8].

1.2 HTTP摘要認證

SIP因其簡單性、較好的可擴展性、易于實現等而廣泛應用，其安全性也越發重要[9].SIP本身不提供認證機制與加密機制，其默認方法是借助于HTTP摘要認證來保證認證鑒權與口令加密傳輸，實現對用戶的身份進行鑒別和抵御重放攻擊[10].

HTTP摘要認證是基于預分配用戶名密碼的一種認證機制，以替代基本認證，防止密碼明文傳輸泄露信息[11].采用質詢-應答機制(chcallenge-response)，“質詢”指服務器向客戶端發送一個包含消息頭WWW-Auhtelliteate的HTTP響應，狀態碼為401(Unauhtiorezd)，要求客戶端發送端認證信息；“應答”指客戶端識別出消息頭后，向服務器反饋基于HTTP的請求信息[12].當服務器收到客戶端的請求消息時,若該客戶端尚未完成身份的認證，則服務器會在回應中發起挑戰,客戶端須提供證明自己身份的信息,以完成服務器對其身份的驗證[13].

2 系統結構設計

本文將視頻監控系統分為中央管理系統(central management system, CMS)、接入網關(access gateway, AG)、媒體分發系統(media distribution system, MDS)、客戶端(multimedia client, MC)以及其他模塊，如圖2所示：

圖2 視頻監控系統結構圖

1) 中央管理系統

CMS是視頻監控系統的中樞管理系統，直接管理AG與其他模塊.作為管理中心提供客戶端用戶管理；作為存儲中心存儲客戶端用戶數據和業務參數配置數據，向Portal提供發布的內容[14].提供客戶端接入時的呼叫控制功能，接收SIP的呼叫請求.如果被叫是本域的前端，則修改SIP消息中的SDP(session description protocol)，根據前端注冊的信令地址發起新的SIP呼叫，失敗則釋放本次呼叫[15].

圖3 登錄流程示意圖

2) 接入網關

AG是系統的前端接入網關，以及Web和WAP客戶端的HTTP Portal，是MC注冊或者會話時的第1個訪問點，部署在MC與CMS之間[14].AG必須實現本域MC的接入，接收和轉發由MC或CMS發來的SIP信令.實現對MC的接入管理，接收、轉發來自MC的呼叫控制信令給CMS，轉發從CMS接收到的請求或應答消息給MC.

3) 媒體分發系統

4) 客戶端

MC分為PC客戶端、手機客戶端，基于Web或者WAP，本文默認為Web.客戶端功能可包括安全接入認證、圖像瀏覽、錄像回放、云鏡控制、快照、解碼、對講等功能，本文只探究安全接入認證.

3 認證設計方案

客戶端的安全接入，首先在訪問視頻監控業務之前必須先在平臺完成有效注冊，確保用戶身份的合法性，當客戶端需要退出視頻監控業務時需要請求注銷.SIP呼叫一次代理服務器(本文中指AG)的過程需要3次握手確認才算完成[16].另外，一個CMS下面可能存在多個MC接入網關，MC接入到哪個MC的接入網關上必須由系統中的CMS進行統一調度,如圖3中的AG(A)，調度方式可采用SIP的302重定向功能來實現，所以MC必須要支持SIP重定向功能:客戶端注冊到平臺時采用客戶端編號進行注冊.且登錄注銷支持NAT穿越功能，支持RFC3581標準.

1) 客戶端(MC)發送Register消息到AG(A),這里的AG(A)是平臺的統一接入網關，即在客戶端上配置的接入網關；

2) AG(A)轉發請求給CMS；

圖4 設備屬性列表流程圖

3) CMS進行調度，并返回302重定向到AG(B)；

4) 客戶端(MC)發送Register消息到接入網關AG(B)；

5) 接入網關AG(B)轉發Register消息到CMS；

6) CMS檢測到Register消息中沒有登錄請求消息，返回401需要鑒權響應；

7) 接入網關AG(B)轉發401需鑒權響應到客戶端(MC)；

8) 客戶端(MC)收到401響應后，發送攜帶鑒權信息的Register消息到接入網關AG(B)；

9) 接入網關AG(B)轉發攜帶鑒權信息的Register消息到CMS；

10) CMS鑒權通過后返回200 OK注冊成功響應消息；

11) 接入網關AG(B)轉發注冊成功響應消息到客戶端(MC).

由于注銷與注冊流程相似，不再贅述注銷原理.注銷和注冊消息的唯一不同就是，注銷時Register消息中的Expires參數等于0，客戶端在注冊時使用用戶名或者用戶ID注冊，后續SIP消息頭中要保持一致，這是SIP協議棧的基本要求.

3.2 獲取設備屬性列表

客戶端經視頻監控業務平臺授權登錄后，需進一步驗證用戶權限，如是否權限過期，是否列入黑名單，有哪些禁止服務權限等.這通過獲取設備屬性列表實現，在設備屬性列表中主要包括3種類型的信息：用戶相關的信息、設備列表信息和設備動態狀態信息，這3個信息分3次不同的請求進行獲取[16].其中用戶相關的信息主要包括用戶本身的權限屬性等信息，設備列表信息主要包括一些設備列表分組和具體的設備列表信息，而設備動態狀態信息主要包括設備IP地址，碼流、狀態等信息，如圖4所示:

1) 客戶端(MC)向AG發送HTTP請求，獲取用戶本身相關的信息，在HTTP請求頭中未攜帶鑒權信息；

2) AG轉發請求給CMS；

3) CMS返回401響應給AG；

4) AG返回401響應給客戶端(MC)，需對客戶端進行鑒權；

5) 客戶端(MC)重新組成HTTP頭，并攜帶鑒權信息向AG發送獲取用戶信息請求消息；

6) AG轉發請求消息給CMS；

7) CMS進行認真鑒權成功之后，并返回具體的用戶相關信息給AG，在響應消息中包括用戶設備列表的時間戳信息；

8) AG轉發給客戶端(MC)；

9) 客戶端(MC)根據設備列表的時間戳和本地保存的時間戳判斷是否需要重新獲取設備靜態列表.如果需要，則發送獲取設備靜態列表給AG,如果時間戳一致，則不需要重新獲取設備靜態列表，直接獲取動態信息；

10) AG轉發請求給CMS；

11) CMS返回設備靜態列表給AG；

12) AG轉發設備靜態列表響應給客戶端(MC)；

13) 客戶端(MC)加載了設備列表之后，向AG繼續獲取具體的設備狀態信息；

14) AG轉發給CMS；

15) CMS返回設備狀態信息給AG；

16) AG轉發響應給客戶端(MC).

3.3 認證流程

在注冊的過程中完成身份認證，AG負責MC的身份認證.MC每次向AG發起HTTP請求AG都需要進行摘要認證.MC首次向AG發送HTTP請求，AG返回401(未授權)響應進行挑戰.401消息的頭里帶有WWW-Authenticate消息頭，其中包含挑戰摘要的隨機參數nonce.MC收到401后，將用戶名密碼和挑戰信息用MD5加密形成認證鑒權頭，重新發送給AG，AG對認證鑒權頭進行驗證，如果認證成功則返回200 OK，并在響應的消息中返回下次認證的隨機數nextnonce，MC下次請求時，根據nextnonce生成鑒權頭進行HTTP請求[17].如圖5所示：

圖5 HTTP摘要認證流程圖

3.4 AG的質詢消息頭

AG的401未授權質詢WWW-Authenticate消息頭語法：

challenge=″Digest″ digest-challenge

digest-challenge=1#(realm|[domain]|nonce|[opaque]|[stale]|[algorithm]|[qop-options]|[auth-param])

domain=″domain″″=″〈″〉URI(1*SP URI)〈″〉

URI=absoluteURI|abs_path

nonce=″nonce″ ″=″nonce-value

nonce-value=quoted-string

opaque=″opaque″ ″=″quoted-string

stale=″stale″ ″=″(″true″|″false″)

algorithm=″algorithm″ ″=″(″MD5″|″MD5-sess″|token)

qop-options=″qop″ ″=″〈″〉1#qop-value〈″〉

qop-value=″auth″|″auth-int″|token

AG的消息頭參數如表1所示：

表1 AG的消息頭參數說明表

3.5 MC的應答消息頭

MC的應答消息頭語法：

credentials=″Digest″ digest-response

digest-response=1#(username|realm|nonce|digest-uri|response|[algorithm]|[cnonce]|[opaque]|[message-qop]|[nonce-count]|[auth-param])

username=″username″ ″=″username-value

username-value=quoted-string

digest-uri=″uri″ ″=″digest-uri-value

digest-uri-value=request-uri;As specified by HTTP1.1

message-qop=″qop″ ″=″qop-value

cnonce=″cnonce″ ″=″cnonce-value

cnonce-value=nonce-value

nonce-count=″nc″ ″=″nc-value

nc-value=8LHEX

response=″response″ ″=″request-digest

request-digest=〈″〉32LHEX〈″〉

LHEX=″0″|″1″|″2″|″3″|″4″|″5″|″6″|″7″|″8″|″9″|″a″|″b″|″c″|″d″|″e″|″f″|

MC的Authorization頭參數如表2所示：

表2 MC的Authorization頭參數說明表

3.6 Response參數

在HTTP摘要認證的“response”過程中，MC通過定義response的不同參數，向AG反饋相應的HTTP請求信息，response參數計算方法至關重要.response參數計算算法參考RFC2617[18]：

response=〈″〉〈KD(H(A1),unq(nonce-value)

″:″ nc-value

″:″ unq(cnonce-value)

″:″ unq(qop-value)

″:″ H(A2)

) 〈″〉

A1=unq(username-value) ″:″ unq(realm-value) ″:″ passwd

如果qop等于auth，A2=Method ″:″ digest-uri-value

如果qop等于auth-int，A2=Method ″:″ digest-uri-value ″:″ H(entity-body)

其中：

1) H(data)=MD5(data).

2) KD(secret,data)=H(concat(secret, ″:″, data)).

3) unq(X)代表去掉X前后的引號.

4) Method=GET或者POST.

5) entity-body代表HTTP請求的消息體.

6) passwd=key.

AG在收到MC的挑戰響應消息后，根據Authorization消息頭中的username參數，取出對應的key和key的有效期，然后使用和MC相同的計算方法，對Authorization消息頭中的參數進行摘要計算，將計算結果與response值進行比較，相同則鑒權成功，返回200 OK響應，不同則鑒權失敗，重新返回401 Unauthorized響應，格式與請求1的401響應相同.鑒權成功后，AG的200 OK響應的消息頭中增加了字段，如表3所示：

表3 HTTP的消息頭增加字段表

4 結束語

隨著智能終端、APP的廣泛應用，視頻監控系統中客戶端的安全接入至關重要.本文中基于SIP與HTTP協議的原理與關系，設計了視頻監控系統中客戶端與接入網關之間的HTTP摘要認證方案，對增強SIP協議的安全性有一定借鑒意義.但是HTTP摘要認證本身仍存在一定缺陷，如不能雙向認證，缺乏私鑰協商機制，不能為SIP協議消息頭域加密等，這些缺陷還需不斷改進.另外，客戶端的安全接入有多種保證機制，需要多方協同.這些將在今后進一步研究探討.

[1]王永建, 徐楊, 王迅, 等. 面向平安城市的視頻監控前端呼叫設計研究[J]. 軟件, 2016, 37(4): 101-106

[2]賀德富, 涂睿, 張紅軍. 軍隊院校信息安全意識教育探析[J]. 信息安全與通信保密, 2014 (12): 71-72

[3]王永建, 劉永濤, 梁偉河, 等. 一種基于SIP的多媒體客戶端安全接入設計[J]. 通信技術, 2016, 49(7): 923-928

[4]劉輝, 羅曉勇,張杰. 基于SIP的無線視頻監控系統的設計與實現[J]. 電視技術, 2011, 35(19): 93-95

[5]曾鷺鷺, 陳一民. 基于SIP協議的IP電話服務器的設計與實現[J]. 計算機工程, 2007, 33(3): 278-280

[6]徐軒. 嵌入式移動視頻采集終端的設計與實現[D]. 武漢: 武漢理工大學, 2013

[7]亢娟. 基于WCDMA網絡的智能公交系統接口協議研究[D]. 太原: 太原理工大學, 2013

[8]陳瑩. 基于SIP協議的視頻監控系統的實現與應用[D]. 上海: 上海交通大學, 2008

[9]李學杰, 金志剛, 戴居豐. 基于HTTP摘要認證的SIP安全性設計[J]. 電子測量技術, 2007, 30(12): 109-115

[10]顧曉輝, 施佳佳, 郭放. SIP的安全機制及其HTTP摘要認證的改進[J]. 東華大學學報: 自然科學版, 2010, 36(2): 165-174

[11]彭煥峰. 一種基于改進的HTTP摘要認證的SIP安全機制[J].微型機與應用,2011,30(6):53-55

[12]陳遠志. HTTP認證及其在Web平臺中的實現[J]. 中國數據通信, 2004, 6(10): 77-83

[13]傅有為. 基于HTTP摘要認證機制的SIP通信系統的實現[D]. 大連: 大連理工大學, 2011

[14]仝玉選. 試論電信級視頻監控中心服務平臺[J]. 現代傳輸, 2011 (6): 55-67

[15]姚楠, 王開圣. 基于三維GIS的電網視頻監控系統[J]. 中國電力, 2012, 45(4): 96-100

[16]Menon V, Kulgod S V, Bangalore J. Fast connect procedure for session initiation protocol using cached credentials[C] //Proc of IEEE 2014 Int Conf on Advances in Computing, Communications and Informatics. New Delhi, India: India Chapter & Res Publishing Serv, 2014: 322-326

[17]中國移動通信集團公司. 中國移動視頻監控接口規范[DB/OL]. [2016-10-16]. http://wenku.baidu.com/view/3a2ec2daad51f01dc281f149.html?from=search,2011-10-19/2016-03-22

[18]IETF. HTTP authentication: Basic and digest access authentication[DB/OL]. [2016-10-16]. https://datatracker.ietf.org/doc/rfc2617/?include_text=1,2013-03-02/2016-03-10

王永建

碩士，高級工程師，IEEE、ACM會員，主要研究方向為信息安全、信息檢索、大數據.

kingselfme@sina.com

張 健

碩士，高級工程師，主要研究方向為數據通信、信息安全.

zhangjian@citcc.cn

鐵小輝

本科，高級工程師，主要研究方向為云計算、信息安全.

tiexiaohui@citcc.cn

楊建華

本科，高級工程師，主要研究方向為信息安全、大數據.

yangjianhua@citcc.cn

郭廣濤

本科，高級工程師，主要研究方向為數據通信、多媒體.

guoguagntao@citcc.cn

Ansafety Authentication Design Based on HTTP Digest for Video Monitoring System

Wang Yongjian, Zhang Jian, Tie Xiaohui, Yang Jianhua, and Guo Guangtao

(ChinaInternationalTelecommunicationConstructionGroupDesignInstituteCo,Ltd,Beijing100079)

The construction of safe city, it is the key ofsecurity authentication forclien in video monitoring system. In order to make up for the lack of security of SIP, an authentication scheme has been designed based on HTTP digest. Firstly, the principle of SIP and HTTP protocol is analyzed, and it designs the whole structure of video monitoring system, and defines the function of each main component. Then, it designs the scheme of logincancellation and achieving the property list of equipment. Finally, it designs the implementation scheme which include scertification process, chcallenge message header of AG, response message header of MC and parameter of Response. The design idea, in the paper, has a certain reference significance for improving the security of SIP protocol.

session initiation protocol; session description protocol; HTTP digest; chanllenge; response

2016-10-14

河南省重點科技攻關項目(122102210430)

TN919.81