本發(fā)明涉及網(wǎng)絡(luò)通信安全，具體涉及一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法。

背景技術(shù)：

1、隨著網(wǎng)絡(luò)通信技術(shù)的飛速發(fā)展和互聯(lián)網(wǎng)應(yīng)用的日益普及，多媒體服務(wù)、直播、點(diǎn)播等業(yè)務(wù)場景如雨后春筍般涌現(xiàn)，音視頻網(wǎng)絡(luò)數(shù)據(jù)量呈現(xiàn)出爆炸式增長。同時(shí)，小程序、微服務(wù)、app等各類應(yīng)用也不斷增多，為用戶提供了更加便捷、豐富的網(wǎng)絡(luò)體驗(yàn)。然而，隨著網(wǎng)絡(luò)應(yīng)用的不斷增多和數(shù)據(jù)量的急劇增加，網(wǎng)絡(luò)通信安全問題也日益凸顯，對于公司或開發(fā)者而言，提升網(wǎng)絡(luò)通信安全以保障服務(wù)質(zhì)量顯得尤為重要。

2、目前，網(wǎng)絡(luò)通信主要依賴于http協(xié)議及其安全版本https協(xié)議來完成。為了保障網(wǎng)絡(luò)通信的安全，業(yè)界采用了多種技術(shù)手段，主要包括：

3、請求方式：使用get或post請求方式進(jìn)行數(shù)據(jù)傳輸。然而，get方式請求的數(shù)據(jù)會暴露在url中，對于敏感信息而言存在安全隱患；而post方式雖然將數(shù)據(jù)傳輸在請求體中，但通過抓包工具如wireshark或tcpdump等仍然可以獲取數(shù)據(jù)的明文信息，安全性有限。

4、數(shù)據(jù)序列化方式：采用json等明文格式進(jìn)行數(shù)據(jù)序列化。這種明文傳輸方式容易被截取和篡改，無法確保數(shù)據(jù)的完整性和機(jī)密性。

5、數(shù)據(jù)加密：使用加密算法對傳輸數(shù)據(jù)進(jìn)行加密處理，以提高數(shù)據(jù)的安全性。然而，加密算法的實(shí)現(xiàn)和密鑰管理本身也存在一定的復(fù)雜性，且加密后的數(shù)據(jù)在特定條件下仍可能面臨被破解的風(fēng)險(xiǎn)。

6、證書簽名：通過https協(xié)議向ca(證書頒發(fā)機(jī)構(gòu))申請證書，并在通信過程中進(jìn)行證書認(rèn)證和密鑰交換。雖然https協(xié)議可以在一定程度上保證通信過程的數(shù)據(jù)安全不被破解，但也可能被一些代理軟件(如fiddler)通過替換證書和更新系統(tǒng)證書的方式截取和破解，存在安全隱患。

7、音視頻數(shù)據(jù)加密：為了保障音視頻數(shù)據(jù)的安全性，一些應(yīng)用采用了音視頻加密技術(shù)。然而，這種加密方法需要大量的客戶端播放器支持，不利于服務(wù)的快速應(yīng)用。同時(shí)，由于播放器眾多且各音視頻廠商的加密方式不統(tǒng)一，給實(shí)際應(yīng)用帶來了很大的困擾。

8、此外，網(wǎng)絡(luò)請求接口容易暴露，存在眾多的模擬請求情況。即使數(shù)據(jù)進(jìn)行了加密處理，攻擊者仍然可以截取加密數(shù)據(jù)并重新封裝請求接口，進(jìn)行惡意攻擊或數(shù)據(jù)竊取。

9、綜上所述，現(xiàn)有網(wǎng)絡(luò)通信技術(shù)在安全性方面存在諸多不足和缺陷。因此，迫切需要一種新的網(wǎng)絡(luò)通信安全技術(shù)，以解決上述問題并提高網(wǎng)絡(luò)通信的安全性和可靠性。旨在提供一種更加安全、高效的網(wǎng)絡(luò)通信方法，以滿足日益增長的網(wǎng)絡(luò)安全需求。

技術(shù)實(shí)現(xiàn)思路

1、針對現(xiàn)有技術(shù)的不足，本發(fā)明提供一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，該方法可以提高網(wǎng)絡(luò)通信的安全性和可靠性，以滿足日益增長的網(wǎng)絡(luò)安全需求。

2、本發(fā)明通過以下技術(shù)方案來實(shí)現(xiàn)上述目的：

3、一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，包括以下步驟：

4、將待發(fā)送數(shù)據(jù)通過probuf進(jìn)行封裝；

5、生成隨機(jī)數(shù)，并根據(jù)隨機(jī)數(shù)從約定的密碼本中獲取加解密密鑰；

6、使用aes對稱加密算法和加解密密鑰對業(yè)務(wù)數(shù)據(jù)進(jìn)行加密；

7、將加密后的業(yè)務(wù)數(shù)據(jù)按照自定義的body數(shù)據(jù)封裝格式進(jìn)行封裝，包括設(shè)置隨機(jī)數(shù)、加密數(shù)據(jù)長度、數(shù)據(jù)序列化方式標(biāo)識、加密后的業(yè)務(wù)數(shù)據(jù)以及循環(huán)校驗(yàn)碼；

8、將封裝好的加密數(shù)據(jù)以及請求頭簽名采用post請求發(fā)送給服務(wù)端；

9、服務(wù)端接收加密數(shù)據(jù)，并驗(yàn)證請求頭簽名；若簽名驗(yàn)證成功，服務(wù)端利用預(yù)定格式對加密數(shù)據(jù)進(jìn)行解密，得到原始數(shù)據(jù)。

10、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，在進(jìn)行接口簽名認(rèn)證時(shí)，客戶端在按照預(yù)定的順序拼接請求頭和請求體以生成待簽名數(shù)據(jù)后，使用雙方預(yù)先約定且包含安全特性的hash算法對待簽名數(shù)據(jù)進(jìn)行處理，以生成簽名字符串；其中，hash算法確保生成的簽名字符串具有唯一性和不可預(yù)測性，且客戶端將簽名字符串作為請求的一部分，與請求頭和請求體一同發(fā)送至服務(wù)器。

11、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，服務(wù)器在接收到客戶端的請求后，按照與客戶端相同的順序拼接接收到的請求頭和請求體，以復(fù)原生成簽名字符串所用的待簽名數(shù)據(jù)；

12、服務(wù)器使用與客戶端相同的hash算法對復(fù)原生成的待簽名數(shù)據(jù)進(jìn)行處理，生成服務(wù)器端的簽名字符串；

13、服務(wù)器將生成的服務(wù)器端簽名字符串與客戶端傳遞的簽名字符串進(jìn)行對比，若兩者一致，則確認(rèn)請求為有效且未被篡改，繼續(xù)處理該請求；若兩者不一致，則判定簽名驗(yàn)證失敗，服務(wù)端丟棄該請求數(shù)據(jù)，不進(jìn)行后續(xù)的解密操作；

14、并且，在簽名驗(yàn)證成功的情況下，服務(wù)端利用與客戶端在請求過程中共同約定或預(yù)先設(shè)定的隨機(jī)數(shù)作為密鑰，對請求中可能包含的加密數(shù)據(jù)進(jìn)行解密操作，以獲取請求的實(shí)際內(nèi)容。

15、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，body數(shù)據(jù)體封裝格式包括：

16、random?number：隨機(jī)數(shù)，占用1個(gè)字節(jié)大小，為隨機(jī)生成的數(shù)值，用作加解密密鑰的獲取基礎(chǔ)；

17、length：表示加密數(shù)據(jù)的長度，占用4個(gè)字節(jié)大小，其值為業(yè)務(wù)數(shù)據(jù)長度與randomnumber進(jìn)行異或運(yùn)算的結(jié)果，用于服務(wù)器解析時(shí)獲取有效數(shù)據(jù)的長度；

18、type：數(shù)據(jù)序列化方式的標(biāo)識，占用1個(gè)字節(jié)大小，用于服務(wù)器根據(jù)該標(biāo)識解析數(shù)據(jù)內(nèi)容；

19、data：為業(yè)務(wù)數(shù)據(jù)經(jīng)過aes加密后的結(jié)果，加密前的數(shù)據(jù)需先按照type指定的序列化方式進(jìn)行序列化處理，序列化后的數(shù)據(jù)再進(jìn)行aes加密；

20、crc：循環(huán)校驗(yàn)碼，占用4個(gè)字節(jié)大小，其值為加密前的業(yè)務(wù)數(shù)據(jù)data直接計(jì)算得出的md5值，用于服務(wù)器在解密并解析數(shù)據(jù)前，校驗(yàn)數(shù)據(jù)的完整性和正確性。

21、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，服務(wù)器在接收到客戶端的請求數(shù)據(jù)后，首先根據(jù)random?number和length計(jì)算出業(yè)務(wù)數(shù)據(jù)的實(shí)際長度，然后依據(jù)type確定數(shù)據(jù)的序列化方式，接著對data進(jìn)行aes解密，并在解密前或解密后利用crc校驗(yàn)碼驗(yàn)證數(shù)據(jù)的正確性，以確保數(shù)據(jù)的安全傳輸和準(zhǔn)確處理。

22、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，在生成隨機(jī)數(shù)后，客戶端和服務(wù)端預(yù)先約定一個(gè)密碼本codebook，密碼本的長度為100；同時(shí)約定加解密密鑰key，加密密鑰的長度為24；

23、其中，加密密鑰的每一位通過以下公式計(jì)算得出：

24、key[i]＝codebook[random?number+i]，其中i為0至23的整數(shù)；

25、隨機(jī)數(shù)的生成規(guī)則為：random?number＝rand()％(100-24)，用于確保隨機(jī)數(shù)在密碼本長度與加密密鑰長度之差的范圍內(nèi)。

26、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，請求簽名的邏輯包括：

27、按照預(yù)定的規(guī)則，根據(jù)請求到達(dá)時(shí)刻的秒數(shù)和分鐘數(shù)的奇偶性，選擇請求頭和請求體中的拼接項(xiàng)以及拼接項(xiàng)的順序。

28、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，當(dāng)秒數(shù)為奇數(shù)時(shí)，選擇的拼接項(xiàng)包括timestamp和cookie；當(dāng)秒數(shù)為偶數(shù)時(shí)，選擇的拼接項(xiàng)包括timestamp、cookie和body；

29、并且，當(dāng)分鐘數(shù)為奇數(shù)時(shí)，拼接項(xiàng)的順序?yàn)閠imestamp、cookie、body，其中，若秒數(shù)為偶數(shù)時(shí)包含body；當(dāng)分鐘數(shù)為偶數(shù)時(shí)，拼接項(xiàng)的順序?yàn)閎ody、cookie、timestamp，其中，若秒數(shù)為奇數(shù)或偶數(shù)時(shí)均按此順序調(diào)整；

30、通過選擇的拼接項(xiàng)及順序進(jìn)行拼接，然后通過hash算法生成簽名字符串x-signature。

31、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，首先，定義probuf消息結(jié)構(gòu)，該結(jié)構(gòu)包括與待發(fā)送數(shù)據(jù)相對應(yīng)的各個(gè)字段及其數(shù)據(jù)類型；然后，將待發(fā)送數(shù)據(jù)按照定義的probuf消息結(jié)構(gòu)進(jìn)行填充；接著，使用probuf編譯器將填充好的消息結(jié)構(gòu)編譯成二進(jìn)制格式的數(shù)據(jù)流；

32、將封裝好的二進(jìn)制格式數(shù)據(jù)流作為請求體的一部分，與生成的請求頭和簽名一同發(fā)送給服務(wù)器；

33、服務(wù)器在接收到請求后，首先解析請求體中的二進(jìn)制格式數(shù)據(jù)流，通過probuf反序列化過程將其還原為原始待發(fā)送數(shù)據(jù)的結(jié)構(gòu)，然后結(jié)合請求頭和簽名進(jìn)行驗(yàn)證和處理。

34、根據(jù)本發(fā)明提供的一種基于http協(xié)議提升網(wǎng)絡(luò)通信安全的數(shù)據(jù)加密及接口簽名方法，將封裝好的加密數(shù)據(jù)以及請求頭簽名采用post請求發(fā)送給服務(wù)端，包括：

35、將封裝好的加密數(shù)據(jù)構(gòu)造為json格式的請求體；

36、生成請求頭，請求頭中至少包含用于標(biāo)識請求內(nèi)容類型的字段，其值設(shè)置為“application/json”，以指示服務(wù)器請求體數(shù)據(jù)為json格式，同時(shí)將簽名字符串作為請求頭的一個(gè)字段發(fā)送，用于服務(wù)器對請求進(jìn)行驗(yàn)證；

37、將構(gòu)造好的請求體和生成的請求頭一同發(fā)送給服務(wù)端；其中，使用http協(xié)議中的post方法，將請求體作為消息正文，將請求頭作為消息頭部分，發(fā)送到服務(wù)端指定的接口地址。

38、由此可見，本發(fā)明針對現(xiàn)有網(wǎng)絡(luò)通信技術(shù)在安全性方面存在的諸多不足和缺陷，提出了一種全新的網(wǎng)絡(luò)通信加密與安全機(jī)制，其有益效果主要體現(xiàn)在以下幾個(gè)方面：

39、1、本發(fā)明設(shè)計(jì)了復(fù)雜密碼本以及隨機(jī)數(shù)加密的方案，使得傳輸?shù)臄?shù)據(jù)在加密過程中具有更高的隨機(jī)性和復(fù)雜性，極大地提高了數(shù)據(jù)被破解的難度，增強(qiáng)了數(shù)據(jù)傳輸?shù)陌踩浴?/p>

40、2、本發(fā)明通過采用pb(probuf)方式序列化數(shù)據(jù)，并自定義實(shí)現(xiàn)隨機(jī)密鑰加密方案，替代了原始的json數(shù)據(jù)序列化方式。pb序列化方式不僅提高了數(shù)據(jù)的傳輸效率，還因其二進(jìn)制格式和自定義加密方案的結(jié)合，有效防止了數(shù)據(jù)在傳輸過程中的被篡改和竊取，進(jìn)一步保障了數(shù)據(jù)的安全性。

41、3、本發(fā)明提出了請求簽名的方案，通過接口請求簽名以及簽名方法的實(shí)現(xiàn)，確保了請求來源的合法性和真實(shí)性。這一機(jī)制有效防止了用戶抓取鏈接后進(jìn)行惡意請求的行為，避免了資源被非法訪問和濫用，從而保護(hù)了服務(wù)提供者的合法權(quán)益，有效解決了防盜鏈問題。

42、4、在本發(fā)明的基礎(chǔ)上，再使用https協(xié)議進(jìn)行證書驗(yàn)證以及加密通信，形成了多重安全防護(hù)機(jī)制，https協(xié)議本身提供了數(shù)據(jù)傳輸過程中的加密和證書驗(yàn)證功能，與本發(fā)明提出的加密方案相結(jié)合，使得數(shù)據(jù)的安全性得到了進(jìn)一步提升。即使攻擊者能夠突破其中一層防護(hù)，也難以突破整體的安全體系，從而確保了通信過程的極高安全性。

43、綜上所述，本發(fā)明在于通過設(shè)計(jì)復(fù)雜密碼本和隨機(jī)數(shù)加密方案、采用pb序列化數(shù)據(jù)和自定義隨機(jī)密鑰加密方案、以及實(shí)現(xiàn)請求簽名和簽名方法來解決防盜鏈問題，并在此基礎(chǔ)上結(jié)合https協(xié)議進(jìn)行證書驗(yàn)證和加密通信，全面提升了網(wǎng)絡(luò)通信的安全性、可靠性和效率。

44、下面結(jié)合附圖和具體實(shí)施方式對本發(fā)明作進(jìn)一步詳細(xì)說明。