專利名稱：一種推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動(dòng)通信技術(shù)領(lǐng)域，特別涉及一種推送業(yè)務(wù)代理網(wǎng)關(guān)(PPG)對(duì) 推送業(yè)務(wù)發(fā)起者(PI)的安全認(rèn)證方法。
背景技術(shù)：
隨著移動(dòng)通訊技術(shù)和計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)的迅速發(fā)展，移動(dòng)終端的普及以及移動(dòng) 終端能力的提高，無線應(yīng)用協(xié)議(WAP)的應(yīng)用也隨之飛速發(fā)展，推送業(yè)務(wù)(PUSH) 作為WAP應(yīng)用的兩大業(yè)務(wù)之一也發(fā)展迅速，廣泛應(yīng)用于多媒體消息、定位等系統(tǒng)。 同時(shí)垃圾PUSH消息也像普通垃圾短信一樣泛濫，其中部分是因?yàn)榘踩哉J(rèn)證不 夠，出現(xiàn)偽裝業(yè)務(wù)提供者(SP)的情況，這嚴(yán)重影響了消費(fèi)者的電信消費(fèi)和正常生 活，也影響了運(yùn)營(yíng)商和SP正常經(jīng)營(yíng)。
傳統(tǒng)的PUSH安全認(rèn)證使用的是源IP地址和用戶名密碼認(rèn)證的方法，這些方 法相對(duì)簡(jiǎn)單，利用互聯(lián)網(wǎng)發(fā)送的明文進(jìn)行認(rèn)證。但I(xiàn)P地址認(rèn)證可以通過IP欺騙 破解，用戶名密碼認(rèn)證也可以通過網(wǎng)絡(luò)截獲用戶和密碼，然后進(jìn)行模擬破解。傳 統(tǒng)的這些認(rèn)證方法其實(shí)幾乎是虛設(shè)的。
安全傳輸層協(xié)議(TLS)使用的體系結(jié)構(gòu)和加密算法比較完善，具有極高的 安全性，單純從安全性角度考慮它已經(jīng)可以解決傳統(tǒng)IP或者用戶名密碼認(rèn)證的 安全問題。但TLS也有一些缺點(diǎn)l.速度慢。TLS由于加密協(xié)商流程復(fù)雜，另 外應(yīng)用層加密還需要額外的時(shí)間，會(huì)延長(zhǎng)實(shí)際應(yīng)用數(shù)據(jù)傳輸和處理時(shí)間。這一影 響對(duì)于請(qǐng)求較多的SP來說是致命的。2.難度大。TLS加密過程對(duì)應(yīng)用開發(fā)技術(shù) 人員水平要求相對(duì)較高，對(duì)一些SP是技術(shù)門檻。3.需要額外費(fèi)用。使用TLS證 書還需要額外的第三方認(rèn)證費(fèi)用。這些缺點(diǎn)也導(dǎo)致無法在實(shí)際PUSH流程中使用 TLS。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是，提供一種PPG對(duì)PI的安全認(rèn)證方法，本發(fā)
明所述方法可高效方便地驗(yàn)證PI的合法性。
一種PPG對(duì)PI的安全認(rèn)證方法，所述方法包括
歩驟一PI選擇加密所需的HTTP (Hypertext Transfer Protocol,超文本 傳輸協(xié)議)頭，并設(shè)置加密摘要表達(dá)式以及加密算法，將所述加密摘要表達(dá)式以 及所述加密算法告知PPG;
歩驟二 PI構(gòu)造包括有鑒權(quán)HTTP頭的PUSH HTTP請(qǐng)求，并發(fā)送給PPG;
歩驟三PPG解析收到的PUSH HTTP請(qǐng)求的HTTP頭，填寫加密摘要表達(dá)式 并使用加密算法得到摘要結(jié)果，與鑒權(quán)HTTP頭的值比較，若一致，則PUSH HTTP 請(qǐng)求合法，鑒權(quán)成功；否則，PUSH HTTP請(qǐng)求非法，鑒權(quán)失敗。
選擇所述加密所需的HTTP頭的原則是
不選擇用于鑒權(quán)的HTTP頭；不選擇可能會(huì)被HTTP代理修改的HTTP頭；每 次選擇的HTTP頭中應(yīng)該至少有一項(xiàng)因請(qǐng)求的變化而不同。 所述加密摘要表達(dá)式是宏表達(dá)式。 所述加密算法為不可逆加密算法。
所述歩驟一進(jìn)一歩包括所述PI在所述加密所需的HTTP頭中選擇作為摘要 基礎(chǔ)的HTTP頭，并根據(jù)選定的作為摘要基礎(chǔ)的HTTP頭設(shè)置加密摘要表達(dá)式。 所述歩驟二具體包括
歩驟21: PI根據(jù)所述加密所需的HTTP頭構(gòu)造PUSH HTTP請(qǐng)求；
步驟22: PI根據(jù)作為摘要基礎(chǔ)的HTTP頭的值填寫所述加密摘要表達(dá)式的實(shí) 際值，并使用加密算法得到摘要結(jié)果；
歩驟23: PI將所述摘要結(jié)果作為鑒權(quán)HTTP頭的值，并將所述的鑒權(quán)HTTP 頭加入到已構(gòu)造的PUSH HTTP請(qǐng)求的HTTP頭中；
步驟24: PI將包括有鑒權(quán)HTTP頭的PUSH HTTP請(qǐng)求發(fā)給PPG。
所述步驟三中所述PPG根據(jù)解析出的作為摘要基礎(chǔ)的HTTP頭的值填寫所 述加密摘要表達(dá)式的實(shí)際值。 所述歩驟三后還包括
推送業(yè)務(wù)HTTP請(qǐng)求合法或者非法時(shí)，所述PPG返回成功處理后的響應(yīng)或者 拒絕處理響應(yīng)給PI。
本發(fā)明所述方法可以和原來的控制方法配合使用，不需要修改HTTP協(xié)議， 不影響原有流程，增加了傳統(tǒng)安全控制方法的安全性，系統(tǒng)設(shè)計(jì)和開發(fā)人員很容 易掌握和使用，可以有效地解決因偽裝SP引起的垃圾PUSH問題。
本發(fā)明引入可協(xié)商的動(dòng)態(tài)摘要消息加密機(jī)制，解決了背景技術(shù)中提到的TLS 中的缺點(diǎn)，達(dá)到了 PUSH安全控制的要求。


圖1是本發(fā)明中PI與PPG的交互圖2是本發(fā)明所述方法流程圖。
具體實(shí)施例方式
下面結(jié)合附圖及實(shí)施例對(duì)本發(fā)明作進(jìn)一步的詳細(xì)描述
如圖1所示，本發(fā)明中PI與PPG的交互圖，PI發(fā)送PUSH HTTP請(qǐng)求，PPG 鑒權(quán)后返回一個(gè)響應(yīng)消息給PI，告知PI是否鑒權(quán)成功。
如圖2所示，本發(fā)明所述PPG對(duì)PID的安全認(rèn)證方法包括以下步驟
步驟201: PI選擇加密所需的HTTP頭，并設(shè)置加密摘要表達(dá)式以及加密算 法，本實(shí)施例選用MD5算法，將所述加密摘要表達(dá)式以及所述加密算法告知PPG;
本歩驟中選擇所述加密所需的HTTP頭的原則是
不選擇用于鑒權(quán)的HTTP頭；不選擇可能會(huì)被HTTP代理修改的HTTP頭；每 次選擇的HTTP頭中應(yīng)該至少有一項(xiàng)因請(qǐng)求的變化而不同。
所述加密摘要表達(dá)式是宏表達(dá)式；所述加密算法為不可逆加密算法。 本步驟還進(jìn)一步包括PI在所述加密所需的HTTP頭中選擇作為摘要基礎(chǔ)的 HTTP頭，然后PI根據(jù)選定的作為摘要基礎(chǔ)的HTTP頭設(shè)置加密摘要表達(dá)式。
例如P工選擇Content-Type、 User-Agent、 Host、 Accept 、 Connection 、
Content-Length作為加密所需的HTTP頭(各HTTP頭的含義見RFC2616)，并選 定其中的Host 、 User-Agent和Content-Length為摘要基礎(chǔ)，則加密摘要表達(dá) 式設(shè)置為
$Content-Type:$User-Agent:$C〇ntent-Length:$Content-Length 上述表達(dá)式為一個(gè)宏表達(dá)式，在其他的實(shí)施方式中，作為摘要基礎(chǔ)的HTTP
頭則為其他組合，這樣做的目的是使得最終的HTTP請(qǐng)求中的鑒權(quán)HTTP頭的值每
次都不相同。
上述HTTP頭的含義如下
Content-Type表示后面的文檔屬于什么MIME (Multipurpose Internet
Mail Extensions,多用途Internet郵件擴(kuò)展)類型； User-Agent表示瀏覽器類型； Host表示初始URL中的主機(jī)和端口 ； Acc印t表示瀏覽器可接受的MIME類型； Connection表示是否需要持久連接； Content-Length表示請(qǐng)求消息正文的長(zhǎng)度。
步驟202: PI根據(jù)選擇的加密所需的HTTP頭構(gòu)造PUSH HTTP請(qǐng)求； 所述HTTP請(qǐng)求的請(qǐng)求體為 POST /push HTTP/1.1
所述HTTP請(qǐng)求的請(qǐng)求頭為
Content-Type: multipart/related; boundary=PMasdfglkjhqwert; type=〃application/xml〃 User-Agent: PI Host: 192.168.1.101:8090 Accept: text/html, image/gif, image/jpeg Connection: keep-alive Content-Length: 626
步驟203: PI根據(jù)所述作為摘要基礎(chǔ)的HTTP頭的值填寫所述加密摘要表達(dá) 式的實(shí)際值，并使用加密算法得到摘要結(jié)果；
加密摘要表達(dá)式填寫了實(shí)際值后為
multipart/related;boundary二PMasdfglkjhqwert; type=〃appli cat i on/xml〃PI:626:626
將上述表達(dá)式作為消息摘要，使用所述不可逆算法計(jì)算得到摘要結(jié)果為
Clc23288ff9f601d906977f31c37fe553。
歩驟204: PI將所述摘要結(jié)果作為"Push-Authorization",即鑒權(quán)HTTP 頭的值，并將所述的鑒權(quán)HTTP頭加入到已構(gòu)造的PUSH HTTP請(qǐng)求的HTTP頭中； 包括有鑒權(quán)HTTP頭的HTTP請(qǐng)求為 POST /push HTTP/1.1
Content-Type: multipart/related; boundary=PMasdfglkjhqwert; type="application/xml〃User-Agent: PI
Host: 192.168.1. 101:8090
Accept: text/html, image/gif， image/jpeg Connection: keep-alive Content-Length: 626
Push-Authorization: dc23288ff9f601d906977f31c37fe553 步驟205: PI將包括有鑒權(quán)HTTP頭的PUSH HTTP請(qǐng)求發(fā)給PPG; 步驟206: PPG解析收到的PUSH HTTP請(qǐng)求的所有HTTP頭； 歩驟207:根據(jù)解析出的作為摘要基礎(chǔ)的HTTP頭的值填寫所述加密摘要表 達(dá)式的實(shí)際值，并使用與PI使用的加密算法相同的加密算法計(jì)算得到摘要結(jié)果； 步驟208: PPG比較所述摘要結(jié)果與解析出的"Push-Authorization"的值
是否一致；若一致，則執(zhí)行步驟209;否則，執(zhí)行步驟210;
步驟209: PI的PUSH HTTP請(qǐng)求合法，鑒權(quán)成功，返回成功處理后的響應(yīng)給
PI;
步驟210: PI的PUSH HTTP請(qǐng)求非法，鑒權(quán)失敗，返回拒絕處理響應(yīng)給PI。 本發(fā)明引入可協(xié)商的動(dòng)態(tài)摘要消息加密機(jī)制，即使PUSH請(qǐng)求在網(wǎng)絡(luò)傳輸?shù)?br> 過程中被人竊取后再被仿造，也會(huì)因?yàn)殍b權(quán)HTTP頭是每次動(dòng)態(tài)變化的而無法成
功鑒權(quán)，這樣就可有效的防止偽SP發(fā)送垃圾PUSH消息。
理論上本發(fā)明所述方法不僅僅適用于PUSH,而適合于所有使用HTTP請(qǐng)求的場(chǎng)合。
上述實(shí)施例只是具體說明本發(fā)明的實(shí)施歩驟，并非限定本發(fā)明的范圍；在不 脫離本發(fā)明的精神和范圍內(nèi)，對(duì)本發(fā)明進(jìn)行修改或者等同替換的，均應(yīng)涵蓋在本 發(fā)明的權(quán)利要求和保護(hù)范圍當(dāng)中。
權(quán)利要求
1、一種推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方法，其特征在于，所述方法包括步驟一推送業(yè)務(wù)發(fā)起者選擇加密所需的HTTP頭，并設(shè)置加密摘要表達(dá)式以及加密算法，將所述加密摘要表達(dá)式以及所述加密算法告知推送業(yè)務(wù)代理網(wǎng)關(guān)；步驟二推送業(yè)務(wù)發(fā)起者構(gòu)造包括有鑒權(quán)HTTP頭的推送業(yè)務(wù)HTTP請(qǐng)求，并發(fā)送給推送業(yè)務(wù)代理網(wǎng)關(guān)；步驟三推送業(yè)務(wù)代理網(wǎng)關(guān)解析收到的推送業(yè)務(wù)HTTP請(qǐng)求的HTTP頭，填寫加密摘要表達(dá)式并使用加密算法得到摘要結(jié)果，與鑒權(quán)HTTP頭的值比較，若一致，則推送業(yè)務(wù)HTTP請(qǐng)求合法，鑒權(quán)成功；否則，推送業(yè)務(wù)HTTP請(qǐng)求非法，鑒權(quán)失敗。
2、 如權(quán)利要求1所述的推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方 法，其特征在于，選擇所述加密所需的HTTP頭的原則是不選擇用于鑒權(quán)的HTTP頭；不選擇可能會(huì)被HTTP代理修改的HTTP頭；每 次選擇的HTTP頭中應(yīng)該至少有一項(xiàng)因請(qǐng)求的變化而不同。
3、 如權(quán)利要求1所述的推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方 法，其特征在于，所述加密摘要表達(dá)式是宏表達(dá)式。
4、 如權(quán)利要求1所述的推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方 法，其特征在于，所述加密算法為不可逆加密算法。
5、 如權(quán)利要求1所述的推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方 法，其特征在于，所述步驟一進(jìn)一步包括所述推送業(yè)務(wù)發(fā)起者在所述加密所需 的HTTP頭中選擇作為摘要基礎(chǔ)的HTTP頭，并根據(jù)選定的作為摘要基礎(chǔ)的HTTP 頭設(shè)置加密摘要表達(dá)式。
6、 如權(quán)利要求1所述的推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方 法，其特征在于，所述步驟二具體包括步驟21:推送業(yè)務(wù)發(fā)起者根據(jù)所述加密所需的HTTP頭構(gòu)造推送業(yè)務(wù)HTTP 請(qǐng)求；歩驟22:推送業(yè)務(wù)發(fā)起者根據(jù)作為摘要基礎(chǔ)的HTTP頭的值填寫所述加密摘 要表達(dá)式的實(shí)際值，并使用加密算法得到摘要結(jié)果；步驟23:推送業(yè)務(wù)發(fā)起者將所述摘要結(jié)果作為鑒權(quán)HTTP頭的值，并將所述 鑒權(quán)HTTP頭加入到已構(gòu)造的推送業(yè)務(wù)HTTP請(qǐng)求的HTTP頭中；步驟24:推送業(yè)務(wù)發(fā)起者將包括有鑒權(quán)HTTP頭的推送業(yè)務(wù)HTTP請(qǐng)求發(fā)給推送業(yè)務(wù)代理網(wǎng)關(guān)。
7、 如權(quán)利要求1所述的推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方 法，其特征在于，所述歩驟三中所述推送業(yè)務(wù)代理網(wǎng)關(guān)根據(jù)解析出的作為摘要 基礎(chǔ)的HTTP頭的值填寫所述加密摘要表達(dá)式的實(shí)際值。
8、 如權(quán)利要求1所述的推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方 法，其特征在于，所述步驟三后還包括推送業(yè)務(wù)HTTP請(qǐng)求合法或者非法時(shí)， 所述推送業(yè)務(wù)代理網(wǎng)關(guān)返回成功處理后的響應(yīng)或者拒絕處理響應(yīng)給推送業(yè)務(wù)發(fā) 起者。
全文摘要
本發(fā)明涉及一種推送業(yè)務(wù)代理網(wǎng)關(guān)對(duì)推送業(yè)務(wù)發(fā)起者的安全認(rèn)證方法，所述方法包括1.推送業(yè)務(wù)發(fā)起者選擇加密所需的HTTP頭，并設(shè)置加密摘要表達(dá)式以及加密算法，將所述加密摘要表達(dá)式以及所述加密算法告知推送業(yè)務(wù)代理網(wǎng)關(guān)；2.推送業(yè)務(wù)發(fā)起者構(gòu)造包括有鑒權(quán)HTTP頭的推送業(yè)務(wù)HTTP請(qǐng)求，并發(fā)送給推送業(yè)務(wù)代理網(wǎng)關(guān)；3.推送業(yè)務(wù)代理網(wǎng)關(guān)解析收到的推送業(yè)務(wù)HTTP請(qǐng)求的HTTP頭，填寫加密摘要表達(dá)式并使用加密算法得到摘要結(jié)果，與鑒權(quán)HTTP頭的值比較，若一致，則推送業(yè)務(wù)HTTP請(qǐng)求合法；否則，推送業(yè)務(wù)HTTP請(qǐng)求非法。本發(fā)明有效地解決了因偽裝業(yè)務(wù)提供者引起的垃圾推送業(yè)務(wù)問題。
文檔編號(hào)H04L29/08GK101350820SQ200810141728
公開日2009年1月21日 申請(qǐng)日期2008年8月29日 優(yōu)先權(quán)日2008年8月29日
發(fā)明者鄒小燕 申請(qǐng)人:中興通訊股份有限公司