基于http接口的加解密方法、裝置及系統(tǒng)的制作方法
【專利摘要】本申請公開了一種基于HTTP接口的加解密方法、裝置及系統(tǒng)。該方法包括：當需要向服務器獲取數(shù)據(jù)時，確定是否存儲了API列表信息；當存儲有所述API列表信息時，從所述API列表信息中獲取待訪問API的API訪問名；以及向所述服務器發(fā)送用于獲取數(shù)據(jù)的HTTP請求；其中，所述HTTP請求包括：含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號；所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文；所述API列表信息包括至少一個API的名字及對應的API訪問名；每個API的所述API訪問名為根據(jù)所述客戶端的設備號對所述API的名字進行加密后的密文。該方法可提高數(shù)據(jù)傳輸?shù)陌踩浴?br>【專利說明】
基于HTTP接口的加解密方法、裝置及系統(tǒng)
技術(shù)領(lǐng)域
[0001 ]本發(fā)明涉及加解密技術(shù)領(lǐng)域，具體而言，涉及一種基于HTTP接口的加解密方法、裝置及系統(tǒng)。
【背景技術(shù)】
[0002]目前大部分的移動客戶端與服務器之間的通信都是基于HTTP接口協(xié)議而進行的。為了保證接口傳輸?shù)陌踩?，保證用戶的利益，通常需要對HTTP接口中傳輸?shù)臄?shù)據(jù)進行加密處理?，F(xiàn)有的幾種加密方式，如HTTP對稱加密方式及非對稱加密方式均存在密文容易被破解，傳輸安全性低的問題，而HTTPS(Hyper Text Transfer Protocol over SecureSocket Layer，超文本傳輸協(xié)議安全)貝Ij由于其方式比較復雜，需要購買安全證書等原因而導致使用成本高。
[0003]在所述【背景技術(shù)】部分公開的上述信息僅用于加強對本發(fā)明的背景的理解，因此它可以包括不構(gòu)成對本領(lǐng)域普通技術(shù)人員已知的現(xiàn)有技術(shù)的信息。

【發(fā)明內(nèi)容】

[0004]有鑒于此，本發(fā)明提供一種基于HTTP接口的加解密方法、裝置及系統(tǒng)，能夠有效提高數(shù)據(jù)傳輸?shù)陌踩郧伊鞒毯唵巍?br>[0005]本發(fā)明的其他特性和優(yōu)點將通過下面的詳細描述變得顯然，或部分地通過本發(fā)明的實踐而習得。
[0006]根據(jù)本發(fā)明的一方面，提供了一種基于HTTP接口的加解密方法，適用于客戶端，包括:當需要向服務器獲取數(shù)據(jù)時，確定是否存儲了API列表信息；當存儲有所述API列表信息時，從所述API列表信息中獲取待訪問API的API訪問名；以及向所述服務器發(fā)送用于獲取數(shù)據(jù)的HTTP請求;其中，所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文；所述API列表信息包括至少一個API的名字及對應的API訪問名；每個API的所述API訪問名為根據(jù)所述客戶端的設備號對所述API的名字進行加密后的密文。
[0007]根據(jù)本發(fā)明的一實施方式，所述方法還包括:當沒有存儲所述API列表信息時，向所述服務器發(fā)送HTTP接口API列表請求；以及接收并存儲所述服務器返回的所述API列表信息;其中，所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號;所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文。
[0008]根據(jù)本發(fā)明的一實施方式，每個API的所述API訪問名為根據(jù)所述客戶端的設備號生成隨機數(shù)、并以所述隨機數(shù)作為密鑰對所述API的名字采用對稱加密方式進行加密后的密文。
[0009]根據(jù)本發(fā)明的一實施方式，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文;所述方法還包括:當確定沒有存儲在所述非對稱加密方式中使用的加密公鑰時，向所述服務器發(fā)送加密公鑰請求；以及接收并存儲從所述服務器接收的所述加密公鑰;其中，所述加密公鑰為采用對稱加密方式加密后的密文，且在所述對稱加密方式中使用的密鑰為所述客戶端的設備號。
[0010]根據(jù)本發(fā)明的另一方面，提供了一種基于HTTP接口的加解密方法，適用于服務器，包括:接收客戶端發(fā)送的HTTP請求，其中所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述待訪問API的API訪問名為根據(jù)所述客戶端的設備號對所述待訪問API的名字進行加密后的密文;從所述HTTP請求中獲取所述客戶端的設備號;對所述第一請求內(nèi)容進行解密，并確定對所述第一請求內(nèi)容是否解密成功；當對所述第一請求內(nèi)容解密成功時，根據(jù)獲取的所述客戶端的設備號，對所述待訪問API的API訪問名進行解密，并確定對所述待訪問API的API訪問名是否解密成功；以及當對所述待訪問API的API訪問名解密成功時，根據(jù)解密后得到的所述待訪問API的名字，獲取所述待訪問API的地址;根據(jù)所述待訪問API的地址，獲得所述HTTP請求的響應結(jié)果;并將所述響應結(jié)果返回給所述客戶端。
[0011]根據(jù)本發(fā)明的一實施方式，所述方法還包括:接收所述客戶端發(fā)送的HTTP接口API列表請求，其中所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號；所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;從所述HTTP接口 API列表請求中獲取所述客戶端的設備號;對所述第二請求內(nèi)容進行解密，并確定對所述第二請求內(nèi)容是否解密成功；當對所述第二請求內(nèi)容解密成功時，根據(jù)所述客戶端的設備號，對存儲的API列表中的每個API的名字進行加密，分別獲得其對應的API訪問名；以及將由每個API的名字及其對應的所述API訪問名組成的API列表信息返回給所述客戶端。
[0012]根據(jù)本發(fā)明的一實施方式，根據(jù)所述客戶端的設備號，對存儲的API列表中的每個API的名字進行加密，分別獲得其對應的API訪問名包括:根據(jù)所述客戶端的設備號生成隨機數(shù)；以所述隨機數(shù)為密鑰，對所述API列表中的每個API的名字以對稱加密方式進行加密，以分別獲得其對應的所述API訪問名；以及以所述客戶端的設備號為緩存密鑰，存儲所述隨機數(shù)。
[0013]根據(jù)本發(fā)明的一實施方式，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文;所述方法還包括:當確定用于所述非對稱加密方式的所述客戶端的設備號對應的密鑰對失效時，或者當對所述第一請求內(nèi)容解密失敗時，或者當對所述待訪問API的API訪問名解密失敗時，或者當對所述第二請求內(nèi)容解密失敗時，向所述客戶端返回密鑰錯誤響應，以使所述客戶端清理存儲的所述API列表信息及所述密鑰對中的公鑰。
[0014]根據(jù)本發(fā)明的一實施方式，所述方法還包括:接收所述客戶端發(fā)送的加密公鑰請求，所述加密公鑰請求包含所述客戶端的設備號;為所述客戶端生成一對密鑰對；以所述客戶端的設備號為緩存密鑰，存儲所述密鑰對，并設置存儲失效時間；以所述客戶端的設備號為密鑰，對所述密鑰對中的公鑰采用對稱加密方式進行加密；以及將加密后的所述密鑰對中的公鑰返回給所述客戶端。
[0015]根據(jù)本發(fā)明的再一方面，提供了一種基于HTTP接口的加解密裝置，適用于客戶端，包括:存儲確定模塊，用于當需要向服務器獲取數(shù)據(jù)時，確定是否存儲了 API列表信息;訪問名獲取模塊，用于當所述存儲確定模塊確定存儲有所述API列表信息時，從所述API列表信息中獲取待訪問API的API訪問名；以及HTTP請求發(fā)送模塊，用于向所述服務器發(fā)送用于獲取數(shù)據(jù)的HTTP請求;其中，所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述API列表信息包括至少一個API的名字及對應的API訪問名；每個API的所述API訪問名為根據(jù)所述客戶端的設備號對所述API的名字進行加密后的密文。
[0016]根據(jù)本發(fā)明的一實施方式，所述裝置還包括:API請求發(fā)送模塊，用于當所述存儲確定模塊確定沒有存儲所述API列表信息時，向所述服務器發(fā)送HTTP接口 API列表請求；以及API列表接收模塊，用于接收并存儲所述服務器返回的所述API列表信息;其中，所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號;所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文。
[0017]根據(jù)本發(fā)明的一實施方式，每個API的所述API訪問名為根據(jù)所述客戶端的設備號生成隨機數(shù)、并以所述隨機數(shù)作為密鑰對所述API的名字采用對稱加密方式進行加密后的密文。
[0018]根據(jù)本發(fā)明的一實施方式，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文;所述裝置還包括:公鑰請求發(fā)送模塊，用于當確定沒有存儲在所述非對稱加密方式中使用的加密公鑰時，向所述服務器發(fā)送加密公鑰請求；以及公鑰接收模塊，用于接收并存儲從所述服務器接收的所述加密公鑰;其中，所述加密公鑰為采用對稱加密方式加密后的密文，且在所述對稱加密方式中使用的密鑰為所述客戶端的設備號。
[0019]根據(jù)本發(fā)明再一方面，提供了一種基于HTTP接口的加解密裝置，適用于服務器，包括:HTTP請求接收模塊，用于接收客戶端發(fā)送的HTTP請求，其中所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述待訪問API的API訪問名為根據(jù)所述客戶端的設備號對所述待訪問API的名字進行加密后的密文；第一設備號獲取模塊，用于從所述HTTP請求中獲取所述客戶端的設備號；第一請求解密模塊，用于對所述第一請求內(nèi)容進行解密，并確定對所述第一請求內(nèi)容是否解密成功;訪問名解密模塊，用于當所述第一請求解密模塊確定對所述第一請求內(nèi)容解密成功時，根據(jù)獲取的所述客戶端的設備號，對所述待訪問API的API訪問名進行解密，并確定對所述待訪問API的API訪問名是否解密成功；以及HTTP請求處理模塊，用于當所述訪問名解密模塊確定對所述待訪問API的API訪問名解密成功時，根據(jù)解密后得到的所述待訪問API的名字，獲取所述待訪問API的地址;根據(jù)所述待訪問API的地址，獲得所述HTTP請求的響應結(jié)果;并將所述響應結(jié)果返回給所述客戶端。
[0020]根據(jù)本發(fā)明的一實施方式，所述裝置還包括:API請求接收模塊，用于接收所述客戶端發(fā)送的HTTP接口 API列表請求，其中所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號;所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;第二設備號讀取模塊，用于從所述HTTP接口 API列表請求中獲取所述客戶端的設備號;第二請求解密模塊，用于對所述第二請求內(nèi)容進行解密，并確定對所述第二請求內(nèi)容是否解密成功;API列表生成模塊，用于當所述第二請求解密模塊確定對所述第二請求內(nèi)容解密成功時，根據(jù)所述客戶端的設備號，對存儲的API列表中的每個API的名字進行加密，分別獲得其對應的API訪問名；以及API列表發(fā)送模塊，用于將由每個API的名字及其對應的所述API訪問名組成的API列表信息返回給所述客戶端。
[0021]根據(jù)本發(fā)明的一實施方式，所述API列表生成模塊包括:隨機數(shù)生成子模塊，用于根據(jù)所述客戶端的設備號生成隨機數(shù);API加密子模塊，用于以所述隨機數(shù)為密鑰，對所述API列表中的每個API的名字以對稱加密方式進行加密，以分別獲得其對應的所述API訪問名；以及隨機數(shù)存儲子模塊，用于以所述客戶端的設備號為緩存密鑰，存儲所述隨機數(shù)。
[0022]根據(jù)本發(fā)明的一實施方式，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文;所述裝置還包括:密鑰錯誤響應模塊，當確定用于所述非對稱加密方式的所述客戶端的設備號對應的密鑰對失效時，或者當所述第一請求解密模塊確定對所述第一請求內(nèi)容解密失敗時，或者當所述訪問名解密模塊確定對所述待訪問API的API訪問名解密失敗時，或者當?shù)诙埱蠼饷苣K確定對所述第二請求內(nèi)容解密失敗時，向所述客戶端返回密鑰錯誤響應，以使所述客戶端清理存儲的所述API列表信息及所述密鑰對中的公鑰。
[0023]根據(jù)本發(fā)明的一實施方式，所述裝置還包括:公鑰請求接收模塊，用于接收所述客戶端發(fā)送的加密公鑰請求，所述加密公鑰請求包含所述客戶端的設備號;密鑰對生成模塊，用于為所述客戶端生成一對密鑰對;密鑰對存儲模塊，用于以所述客戶端的設備號為緩存密鑰，存儲所述密鑰對，并設置存儲失效時間；公鑰加密模塊，用于以所述客戶端的設備號為密鑰，對所述密鑰對中的公鑰采用對稱加密方式進行加密；以及公鑰發(fā)送模塊，用于將加密后的所述密鑰對中的公鑰返回給所述客戶端。
[0024]根據(jù)本發(fā)明的再一方面，提供了一種基于HTTP接口的加解密系統(tǒng)，適用于客戶端，包括:處理器；以及存儲器，用于存儲所述處理器的可執(zhí)行指令;其中所述處理器配置為經(jīng)由執(zhí)行所述可執(zhí)行指令來執(zhí)行以下操作:當需要向服務器獲取數(shù)據(jù)時，確定是否存儲了API列表信息；當存儲有所述API列表信息時，從所述API列表信息中獲取待訪問API的API訪問名；以及向所述服務器發(fā)送用于獲取數(shù)據(jù)的HTTP請求;其中，所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述API列表信息包括至少一個API的名字及對應的API訪問名；每個API的所述API訪問名為根據(jù)所述客戶端的設備號對所述API的名字進行加密后的密文。
[0025]根據(jù)本發(fā)明再一方面，提供了一種基于HTTP接口的加解密系統(tǒng)，適用于服務器，包括:處理器；以及存儲器，用于存儲所述處理器的可執(zhí)行指令;其中所述處理器配置為經(jīng)由執(zhí)行所述可執(zhí)行指令來執(zhí)行以下操作:接收客戶端發(fā)送的HTTP請求，其中所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述待訪問API的API訪問名為根據(jù)所述客戶端的設備號對所述待訪問API的名字進行加密后的密文;從所述HTTP請求中獲取所述客戶端的設備號；對所述第一請求內(nèi)容進行解密，并確定對所述第一請求內(nèi)容是否解密成功；當對所述第一請求內(nèi)容解密成功時，根據(jù)獲取的所述客戶端的設備號，對所述待訪問API的API訪問名進行解密，并確定對所述待訪問API的API訪問名是否解密成功；以及當對所述待訪問API的API訪問名解密成功時，根據(jù)解密后得到的所述待訪問API的名字，獲取所述待訪問API的地址;根據(jù)所述待訪問API的地址，獲得所述HTTP請求的響應結(jié)果;并將所述響應結(jié)果返回給所述客戶端。
[0026]根據(jù)本發(fā)明的基于HTTP接口的加解密方法，在所傳輸?shù)腍TTP接口數(shù)據(jù)中采用兩級的加密方式，除了對傳輸內(nèi)容進行加密外，HTTP請求中的API名字也是根據(jù)客戶端的設備號進行加密的密文，從而起到保護API地址的作用。相比于現(xiàn)有技術(shù)，該方法流程簡單，且密鑰不容易被破解，提高了數(shù)據(jù)傳輸?shù)陌踩浴?br>[0027]應當理解的是，以上的一般描述和后文的細節(jié)描述僅是示例性的，并不能限制本發(fā)明。
【附圖說明】
[0028]通過參照附圖詳細描述其示例實施例，本發(fā)明的上述和其它目標、特征及優(yōu)點將變得更加顯而易見。
[0029]圖1是根據(jù)部分實施方式示出的本發(fā)明所涉及的網(wǎng)絡架構(gòu)的示意圖。
[0030]圖2是根據(jù)一示例性實施方式示出的一種基于HTTP接口的加解密方法的流程圖。
[0031]圖3是根據(jù)一示例性實施方式示出的另一種基于HTTP接口的加解密方法的流程圖。
[0032]圖4是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密方法的流程圖。
[0033]圖5是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密方法的流程圖。
[0034]圖6是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密方法的流程圖。
[0035]圖7是根據(jù)一示例性實施方式示出的一種基于HTTP接口的加解密裝置的框圖。
[0036]圖8是根據(jù)一示例性實施方式示出的另一種基于HTTP接口的加解密裝置的框圖。
[0037]圖9是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密裝置的框圖。
[0038]圖10是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密裝置的框圖。
[0039]圖11是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密裝置的框圖。
【具體實施方式】
[0040]現(xiàn)在將參考附圖更全面地描述示例實施方式。然而，示例實施方式能夠以多種形式實施，且不應被理解為限于在此闡述的范例;相反，提供這些實施方式使得本發(fā)明將更加全面和完整，并將示例實施方式的構(gòu)思全面地傳達給本領(lǐng)域的技術(shù)人員。附圖僅為本發(fā)明的示意性圖解，并非一定是按比例繪制。圖中相同的附圖標記表示相同或類似的部分，因而將省略對它們的重復描述。
[0041]此外，所描述的特征、結(jié)構(gòu)或特性可以以任何合適的方式結(jié)合在一個或更多實施方式中。在下面的描述中，提供許多具體細節(jié)從而給出對本發(fā)明的實施方式的充分理解。然而，本領(lǐng)域技術(shù)人員將意識到，可以實踐本發(fā)明的技術(shù)方案而省略所述特定細節(jié)中的一個或更多，或者可以采用其它的方法、組元、裝置、步驟等。在其它情況下，不詳細示出或描述公知結(jié)構(gòu)、方法、裝置、實現(xiàn)或者操作以避免喧賓奪主而使得本發(fā)明的各方面變得模糊。
[0042]為了便于理解本發(fā)明的【具體實施方式】，先對本發(fā)明所涉及的網(wǎng)絡架構(gòu)進行說明。圖1是根據(jù)部分實施方式示出的本發(fā)明所涉及的網(wǎng)絡架構(gòu)的示意圖。如圖1所示，網(wǎng)絡架構(gòu)I包括:客戶端2和服務器3。
[0043]客戶端2可以實現(xiàn)于智能手機、平板電腦、筆記本電腦等智能終端中?？蛻舳?可以包括:加解密組件模塊21及接口內(nèi)容處理模塊22。
[0044]加解密組件模塊21用于從服務器3獲取加解密密鑰，根據(jù)密鑰執(zhí)行加解密操作。加解密組件模塊21例如可以實施為一個C或C++語言編寫的組件(Android操作系統(tǒng)以.so文件提供，1S操作系統(tǒng)以.a文件提供)，采用這種方式可以避免加解密方式被破解。
[0045]接口內(nèi)容處理模塊22用于處理與服務器3之間的接口消息，如發(fā)起請求及接收返回內(nèi)容等。
[0046]服務器3可以包括:加解密模塊31、接口管理模塊32及接口處理模塊33。
[0047]加解密模塊31用于對從客戶端2接收的HTTP請求以及給客戶端返回的HTTP響應進行加解密處理。
[0048]接口管理模塊32 用于對API (Applicat1n Program Interface，應用程序接口)的名字進行管理。
[0049]接口處理模塊33用于處理與客戶端2之間接口的業(yè)務邏輯。
[0050]以上對本發(fā)明所涉及的網(wǎng)絡架構(gòu)進行了說明，下面將進一步描述本發(fā)明所公開的【具體實施方式】。
[0051]圖2是根據(jù)一示例性實施方式示出的一種基于HTTP接口的加解密方法的流程圖，該方法可應用于圖1所示的客戶端2中。如圖2所示，該方法10包括:
[0052]在步驟S102中，當需要向服務器3獲取數(shù)據(jù)時，確定是否存儲了API列表信息。
[0053]例如，當客戶端2接收到用戶的某個操作而需要向服務器3獲取數(shù)據(jù)時，客戶端2確定是否存儲了 API列表信息。
[0054]該API列表信息包括至少一個API的信息，每個API的信息至少包括:該API的名字及其訪問名。其中，該API的名字為明文，而該API的訪問名為對API的名字進行加密后的密文，具體地API的訪問名為由服務器3提供的根據(jù)客戶端2的設備號對API的名字進行加密后得到的密文。
[0055]在步驟S104中，當存儲了API列表信息時，從API列表信息中獲取待訪問的API對應的API訪問名。
[0056]例如，可以由客戶端2的接口內(nèi)容處理模塊22先判斷客戶端2中是否存儲有API列表信息。當內(nèi)容處理模塊22判斷客戶端2中存儲了API列表信息時，由加解密組件模塊21從API列表信息中獲取待訪問的API對應的API訪問名。
[0057]在步驟S106中，向服務器3發(fā)起HTTP請求。
[0058]該HTTP請求中包括:含有待訪問API的訪問名的請求內(nèi)容以及客戶端2的設備號，其中請求內(nèi)容為密文，客戶端2的設備號為明文。其中，設備號為可以唯一標識客戶端2所應用的終端設備的設備標號，如可以為移動終端設備的IMEI (Internat1nal Mobi IeEquipment Identity，國際移動設備標識)，或者也可以是移動終端設備中安裝的SIM卡的標號IMSI(Internat1nal Mobile Subscriber Identificat1n Number，國際移動用戶識別碼)，再或者也可以是終端設備的(PU標號、網(wǎng)卡標號等，本發(fā)明不以此為限。
[0059]例如，可以由加解密組件模塊21對請求內(nèi)容進行加密，如上所述，該請求內(nèi)容中包括有API的訪問名。對請求內(nèi)容的加密方式可以為對稱加密，即客戶端2和服務器3中采用固定的密鑰，且兩者采用的密鑰一致?？蛻舳?和服務器3采用相同的且固定的密鑰分別進行傳輸數(shù)據(jù)的加解密操作?；蛘?，也可以采用非對稱加密，即服務器3根據(jù)客戶端2的請求，隨機生成一對密鑰對，并將其中的公鑰返回給客戶端2。之后在數(shù)據(jù)傳輸過程中，客戶端2采用公鑰進行加解密操作，服務器3則采用私鑰進行加解密操作。為了提高加解密的安全性，本發(fā)明實施方式優(yōu)選非對稱加密方式。
[0060]本發(fā)明實施方式的基于HTTP接口的加解密方法，在所傳輸?shù)腍TTP接口數(shù)據(jù)中采用兩級的加密方式，除了對傳輸內(nèi)容進行加密外，HTTP請求中的API名字也是根據(jù)客戶端的設備號進行加密的密文，從而起到保護API地址的作用。相比于現(xiàn)有技術(shù)，該方法流程簡單，且密鑰不容易被破解，提高了數(shù)據(jù)傳輸?shù)陌踩浴?br>[0061]圖3是根據(jù)一示例性實施方式示出的另一種基于HTTP接口的加解密方法的流程圖，該方法可應用于圖1所示的服務器3中。如圖3所示，該方法20包括:
[0062]在步驟S202中，接收客戶端2發(fā)送的HTTP請求。
[0063]例如，由服務器3的接口處理模塊33接收客戶端2發(fā)送的HTTP請求。
[0064]在步驟S204中，從HTTP請求中讀取客戶端2的設備號。
[0065]例如，由加解密模塊31從HTTP請求中讀取客戶端2的設備號。
[0066]在步驟S206中，對HTTP請求中的請求內(nèi)容進行解密。
[0067]在本步驟中，如果該HTTP請求中的請求內(nèi)容采用的是對稱加密方式，則服務器3使用與客戶端2相同的固定密鑰，對請求內(nèi)容進行解密。
[0068]而如果該HTTP請求中的請求內(nèi)容采用的是非對稱加密方式，則服務器3首先根據(jù)讀取的客戶端2的設備號，檢測該設備號對應存儲的密鑰對是否失效，例如可以通過加解密模塊31進行該檢測。當服務器3檢測到該設備號對應的密鑰對沒有失效時，根據(jù)獲取的密鑰對中的私鑰對HTTP請求的內(nèi)容進行解密;而當服務器3檢測到該設備號對應的密鑰對失效時，服務器3可以向客戶端2返回密鑰錯誤的響應，以使客戶端2清理其存儲的密鑰對信息以及API列表信息。
[0069]在步驟S208中，判斷對HTTP請求中的請求內(nèi)容是否解密成功，如果解密成功則進入步驟S210;否則，進入步驟S220。
[0070]例如可以由服務器3的加解密模塊31執(zhí)行上述判斷。
[0071]在步驟S210中，根據(jù)讀取的客戶端2的設備號，對該請求內(nèi)容中的API訪問名進行解密。
[0072]例如，可以由服務器3的加解密模塊31進行該解密操作。在一些實施例中，首先，月艮務器3根據(jù)讀取的客戶端2的設備號，獲取存儲的隨機數(shù)信息；其次，服務器3以該隨機數(shù)信息對API訪問名進行解密。
[0073]在步驟S212中，判斷對API訪問名的解密是否成功，如果成功則進入步驟S214中；否則，進入步驟S220。
[0074]例如可以由服務器3的加解密模塊31執(zhí)行上述判斷。
[0075]在步驟S214中，得到該API訪問名對應的API的名字，以獲取該API的地址。
[0076]例如，可以由服務器3的加解密模塊31執(zhí)行上述操作。
[0077]在步驟S216中，處理該HTTP請求，根據(jù)獲取的API地址，獲得響應結(jié)果。
[0078]例如，可以由服務器3的接口處理模塊33執(zhí)行上述操作。
[0079]在步驟S218中，對響應結(jié)果進行加密后，將密文返回給客戶端2。
[0080]例如，可以由加解密模塊31進行該加密操作，再由接口處理模塊33將加密后的響應結(jié)果返回給客戶端2。[0081 ]其中，對響應結(jié)果可以采用對稱加密，也可以采用非對稱加密。本發(fā)明實施方式優(yōu)選采用非對稱加密，且非對稱加密所使用的密鑰對與對HTTP請求的請求內(nèi)容所采用的非對稱加密的密鑰對相同。但本發(fā)明不以此為例。
[0082]在步驟S220中，向客戶端2返回密鑰錯誤響應，以使客戶端2清理其所存儲的API列表信息。
[0083 ]需要說明的是，如果客戶端2與服務器3之間的接口數(shù)據(jù)(包括HTTP請求、HTTP接口API列表請求、響應結(jié)果等)傳輸采用的是非對稱加解密，則服務器3向客戶端2返回密鑰錯誤響應，則還需要使客戶端2清理其所存儲的密鑰對信息。
[0084]本發(fā)明實施方式的基于HTTP接口的加解密方法，在所傳輸?shù)腍TTP接口數(shù)據(jù)中采用兩級的加密方式，除了對傳輸內(nèi)容進行加密外，HTTP請求中的API名字也是根據(jù)客戶端的設備號進行加密的密文，從而起到保護API地址的作用。相比于現(xiàn)有技術(shù)，該方法流程簡單，且密鑰不容易被破解，提高了數(shù)據(jù)傳輸?shù)陌踩浴?br>[0085]應清楚地理解，本發(fā)明描述了如何形成和使用特定示例，但本發(fā)明的原理不限于這些示例的任何細節(jié)。相反，基于本發(fā)明公開的內(nèi)容的教導，這些原理能夠應用于許多其它實施方式。
[0086]圖4是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密方法的流程圖，該方法可應用于圖1所示的客戶端2中。如圖4所示，該方法30包括:
[0087]在步驟S302中，當準備向服務器3發(fā)起獲取數(shù)據(jù)的HTTP請求，而沒有存儲API列表信息時，或者當接收到服務器3返回的密鑰錯誤響應時，向服務器3發(fā)送HTTP接口 API列表請求。
[0088]API列表請求中包括請求內(nèi)容和客戶端2的設備號。其中請求內(nèi)容為經(jīng)加密處理的密文，設備號則以明文傳遞。
[0089]例如，可以由加解密組件模塊21對請求內(nèi)容進行加密。對請求內(nèi)容的加密方式可以采用對稱加密，也可以采用非對稱加密。本實施方式優(yōu)選采用非對稱加密。而當采用非對稱加密時，客戶端2的加解密組件模塊21還需要判斷當前是否存儲有非對稱加密所使用的公鑰。如果沒有存儲該公鑰，客戶端2還需要向服務器3發(fā)起加密公鑰請求，該請求中攜帶有客戶端2的設備號。并等待服務器3返回所請求的公鑰。在一些實施例中，服務器3返回的該公鑰還可以是以客戶端2的設備號作為固定密鑰進行對稱加密處理的密文。因此客戶端2還需要使用其設備號作為密鑰解密該公鑰的密文，從而得到該公鑰。
[0090]在步驟S304中，接收并存儲服務器3發(fā)送的API列表信息。
[0091]如上所述，該API列表信息中包括至少一個API的信息，每個API的信息至少包括:該API的名字及其訪問名。其中，該API的名字為明文，而該API的訪問名為對API的名字進行加密后的密文，具體地API的訪問名為由服務器3提供的根據(jù)客戶端2的設備號對API的名字進行加密后得到的密文。
[0092]本發(fā)明實施方式的基于HTTP接口的加解密方法，進一步提供了客戶端如何從服務器獲取API列表信息的方法，API列表信息中包括有每個API的名字及對應的API訪問名，其中API訪問名為API名字的密文。從而使得客戶端在發(fā)起HTTP請求時，能夠在請求中攜帶有經(jīng)服務器根據(jù)客戶端的設備號加密的密文API名稱。
[0093]圖5是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密方法的流程圖，該方法可應用于圖1所示的服務器3中。如圖5所示，該方法40包括:
[0094]在步驟S402中，接收客戶端2發(fā)送的HTTP接口API列表請求。
[0095]例如，由服務器3的接口處理模塊33接收客戶端2發(fā)送的HTTP接口API列表請求。
[0096]在步驟S404中，從HTTP接口API列表請求中讀取客戶端2的設備號。
[0097]例如，由加解密模塊31從HTTP接口API列表請求中讀取客戶端2的設備號。
[0098]在步驟S406中，對HTTP接口API列表請求中的請求內(nèi)容進行解密。
[0099]在本步驟中，如果該HTTP接口 API列表請求中的請求內(nèi)容采用的是對稱加密方式，則服務器3使用與客戶端2相同的固定密鑰，對請求內(nèi)容進行解密。
[0100]而如果該HTTP接口API列表請求中的請求內(nèi)容采用的是非對稱加密方式，則服務器3首先根據(jù)讀取的客戶端2的設備號，檢測該設備號對應存儲的密鑰對是否失效，例如可以通過加解密模塊31進行該檢測。當服務器3檢測到該設備號對應的密鑰對沒有失效時，根據(jù)獲取的密鑰對中的私鑰對HTTP接口 API列表請求的內(nèi)容進行解密;而當服務器3檢測到該設備號對應的密鑰對失效時，服務器3可以向客戶端2返回密鑰錯誤的響應，以使客戶端2清理其存儲的密鑰對信息以及API列表信息。
[0101]在步驟S408中，判斷對HTTP接口 API列表請求中的請求內(nèi)容是否解密成功，如果解密成功則進入步驟S410;否則，進入步驟S412。
[0102]例如可以由服務器3的加解密模塊31執(zhí)行上述判斷。
[0103]在步驟S410中，根據(jù)客戶端2的設備號，對存儲的API列表中的每個API的名字進行加密，獲得其對應的API訪問名；并將由API名字及其訪問名組成的API列表信息返回給客戶端2 ο
[0104]例如，可以由加解密模塊31調(diào)用接口管理模塊32，得到原始API列表，獲取各API的名字后，根據(jù)設備號，對各API名字進行加密。
[0105]在一些實施例中，服務器3根據(jù)客戶端2的設備號生成隨機數(shù)信息，并將該隨機數(shù)信息以設備號為存儲密鑰存儲起來。例如，可以長期存儲，也可以設置失效時間，可以在實際應用中根據(jù)實際需求而設定，本發(fā)明不以此為限。之后，服務器3以該隨機數(shù)信息為密鑰，對存儲的API列表中的每個API的名字進行對稱加密，獲得其對應的API訪問名。
[0106]在步驟S412中，向客戶端2返回密鑰錯誤響應，以使客戶端2清理其所存儲的API列表信息。
[0107]需要說明的是，如果客戶端2與服務器3之間的接口數(shù)據(jù)(包括HTTP請求、HTTP接口API列表請求、響應結(jié)果等)傳輸采用的是非對稱加解密，則服務器3向客戶端2返回密鑰錯誤響應，則還需要使客戶端2清理其所存儲的密鑰對信息。
[0108]本發(fā)明實施方式的基于HTTP接口的加解密方法，進一步提供了服務器如何根據(jù)客戶端的請求，生成API列表信息，并將該API列表信息返回給客戶端存儲的方法。
[0109]圖6是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密方法的流程圖，該方法可應用于圖1所示的服務器3中。如圖6所示，該方法50包括:
[0110]在步驟S502中，接收客戶端2發(fā)送的加密公鑰請求，該加密公鑰請求中包含有客戶端2的設備號。
[0111]例如，可以由服務器3的接口處理模塊33執(zhí)行該接收操作。
[0112]在步驟S504中，為客戶端2生成一對密鑰對。
[0113]例如，可以由服務器3的加解密模塊31生成該密鑰對。
[0114]在一些實施例中，服務器3還可以讀取加密公鑰請求中的設備號，以該設備號為密鑰，采用對稱加密方式對該公鑰進行對稱加密，生成該公鑰加密后的密文。
[0115]在步驟S506中，以設備號為緩存密鑰，存儲該密鑰對，并為其設置緩存失效時間。
[0116]在步驟S508中，將該密鑰對中的公鑰返回給客戶端2。
[0117]在一些實施例中，如果服務器3還對該公鑰進行了加密，則將該公鑰的密文返回給客戶端2。
[0118]本發(fā)明實施方式的基于HTTP接口的加解密方法，進一步提供了服務器如何基于客戶端的加密公鑰請求，為客戶端生成加密密鑰對，并將該密鑰對返回給客戶端的方法。
[0119]需要說明的是，對于上述各基于HTTP接口的加解密方法，本發(fā)明不限定其采用的具體加密算法。在實際應用中，可以根據(jù)實際需求而進行設定，如DES算法等。
[0120]本領(lǐng)域技術(shù)人員可以理解實現(xiàn)上述實施方式的全部或部分步驟被實現(xiàn)為由CPU執(zhí)行的計算機程序。在該計算機程序被(PU執(zhí)行時，執(zhí)行本發(fā)明提供的上述方法所限定的上述功能。所述的程序可以存儲于一種計算機可讀存儲介質(zhì)中，該存儲介質(zhì)可以是只讀存儲器，磁盤或光盤等。
[0121]此外，需要注意的是，上述附圖僅是根據(jù)本發(fā)明示例性實施方式的方法所包括的處理的示意性說明，而不是限制目的。易于理解，上述附圖所示的處理并不表明或限制這些處理的時間順序。另外，也易于理解，這些處理可以是例如在多個模塊中同步或異步執(zhí)行的。
[0122]下述為本發(fā)明裝置實施例，可以用于執(zhí)行本發(fā)明方法實施例。對于本發(fā)明裝置實施例中未披露的細節(jié)，請參照本發(fā)明方法實施例。
[0123]圖7是根據(jù)一示例性實施方式示出的一種基于HTTP接口的加解密裝置的框圖，該裝置可應用于圖1所示的客戶端2中。如圖7所示，該裝置60包括:存儲確定模塊602、訪問名獲取模塊604及HTTP請求發(fā)送模塊606。
[0124]存儲確定模塊602用于當需要向服務器獲取數(shù)據(jù)時，確定是否存儲了API列表信息。
[0125]訪問名獲取模塊604用于當所述存儲確定模塊602確定存儲有所述API列表信息時，從所述API列表信息中獲取待訪問API的API訪問名。
[0126]HTTP請求發(fā)送模塊606用于向所述服務器發(fā)送用于獲取數(shù)據(jù)的HTTP請求。
[0127]其中，所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文。
[0128]所述API列表信息包括至少一個API的名字及對應的API訪問名；每個API的所述API訪問名為根據(jù)所述客戶端的設備號對所述API的名字進行加密后的密文。
[0129]在一些實施例中，每個API的所述API訪問名為根據(jù)所述客戶端的設備號生成隨機數(shù)、并以所述隨機數(shù)作為密鑰對所述API的名字采用對稱加密方式進行加密后的密文。
[0130]圖8是根據(jù)一示例性實施方式示出的另一種基于HTTP接口的加解密裝置的框圖，該裝置可應用于圖1所示的客戶端2中。與圖7所示的裝置60不同的是，圖8所示的裝置70還包括:API請求發(fā)送模塊702及API列表接收模塊704。
[0131]API請求發(fā)送模塊702用于當所述存儲確定模塊602確定沒有存儲所述API列表信息時，向所述服務器發(fā)送HTTP接口 API列表請求。
[0132]其中，所述HTTP接口API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號；所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文。
[0133]API列表接收模塊704用于接收并存儲所述服務器返回的所述API列表信息。
[0134]在一些實施例中，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文。裝置70還包括:公鑰請求發(fā)送模塊(圖中未示出)及公鑰接收模塊(圖中未示出)。其中，公鑰請求發(fā)送模塊用于當確定沒有存儲在所述非對稱加密方式中使用的加密公鑰時，向所述服務器發(fā)送加密公鑰請求。公鑰接收模塊用于接收并存儲從所述服務器接收的所述加密公鑰。
[0135]在一些實施例中，所述加密公鑰為采用對稱加密方式加密后的密文，且在所述對稱加密方式中使用的密鑰為所述客戶端的設備號。
[0136]圖9是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密裝置的框圖，該裝置可應用于圖1所示的服務器3中。如圖9所示，該裝置80包括:HTTP請求接收模塊802、第一設備號獲取模塊804、第一請求解密模塊806、訪問名解密模塊808以及HTTP請求處理模塊 810。
[0137]HTTP請求接收模塊802用于接收客戶端發(fā)送的HTTP請求，其中所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述待訪問API的API訪問名為根據(jù)所述客戶端的設備號對所述待訪問API的名字進行加密后的密文。
[0138]第一設備號獲取模塊804用于從所述HTTP請求中獲取所述客戶端的設備號.
[0139]第一請求解密模塊806用于對所述第一請求內(nèi)容進行解密，并確定對所述第一請求內(nèi)容是否解密成功。
[0140]訪問名解密模塊808用于當所述第一請求解密模塊806確定對所述第一請求內(nèi)容解密成功時，根據(jù)獲取的所述客戶端的設備號，對所述待訪問API的API訪問名進行解密，并確定對所述待訪問API的API訪問名是否解密成功。
[0141]HTTP請求處理模塊810用于當所述訪問名解密模塊808確定對所述待訪問API的API訪問名解密成功時，根據(jù)解密后得到的所述待訪問API的名字，獲取所述待訪問API的地址;根據(jù)所述待訪問API的地址，獲得所述HTTP請求的響應結(jié)果;并將所述響應結(jié)果返回給所述客戶端。
[0142]在一些實施例中，所述第一請求內(nèi)容為采用非對稱加密方式加密后的密文。該裝置80還包括:密鑰錯誤響應模塊(圖中未示出)，用于當確定用于所述非對稱加密方式的所述客戶端的設備號對應的密鑰對失效時，或者當所述第一請求解密模塊806確定對所述第一請求內(nèi)容解密失敗時，或者當所述訪問名解密模塊808確定對所述待訪問API的API訪問名解密失敗時，向所述客戶端返回密鑰錯誤響應，以使所述客戶端清理存儲的所述API列表信息及所述密鑰對中的公鑰。
[0143]圖10是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密裝置的框圖，該裝置可應用于圖1所示的服務器3中。與圖9所示的裝置80不同的是，圖10所示的裝置90還包括:API請求接收模塊902、第二設備號讀取模塊904、第二請求解密模塊906、API列表生成模塊908及API列表發(fā)送模塊910。
[0144]API請求接收模塊902用于接收所述客戶端發(fā)送的HTTP接口 API列表請求，其中所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號;所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文；
[0145]第二設備號讀取模塊904用于從所述HTTP接口API列表請求中獲取所述客戶端的設備號；
[0146]第二請求解密模塊906用于對所述第二請求內(nèi)容進行解密，并確定對所述第二請求內(nèi)容是否解密成功；
[0147]API列表生成模塊908用于當所述第二請求解密模塊906確定對所述第二請求內(nèi)容解密成功時，根據(jù)所述客戶端的設備號，對存儲的API列表中的每個API的名字進行加密，分別獲得其對應的API訪問名；以及
[0148]API列表發(fā)送模塊910用于將由每個API的名字及其對應的所述API訪問名組成的API列表信息返回給所述客戶端。
[0149]在一些實施例中，API列表發(fā)送模塊910包括:隨機數(shù)生成子模塊9102、API加密子模塊9104及隨機數(shù)存儲子模塊9106。隨機數(shù)生成子模塊9102用于根據(jù)所述客戶端的設備號生成隨機數(shù)。API加密子模塊9104用于以所述隨機數(shù)為密鑰，對所述API列表中的每個API的名字以對稱加密方式進行加密，以分別獲得其對應的所述API訪問名。隨機數(shù)存儲子模塊9106用于以所述客戶端的設備號為緩存密鑰，存儲所述隨機數(shù)。
[0150]在一些實施例中，所述第二請求內(nèi)容也為采用非對稱加密方式加密后的密文。該裝置90也還包括:密鑰錯誤響應模塊(圖中未示出)。密鑰錯誤響應模塊還用于當?shù)诙埱蠼饷苣K906確定對所述第二請求內(nèi)容解密失敗時，向所述客戶端返回密鑰錯誤響應，以使所述客戶端清理存儲的所述API列表信息及所述密鑰對中的公鑰。
[0151]圖11是根據(jù)一示例性實施方式示出的再一種基于HTTP接口的加解密裝置的框圖，該裝置可應用于圖1所示的服務器3中。與圖9所示的裝置80不同的是，圖11所示的裝置100還包括:公鑰請求接收模塊1002、密鑰對生成模塊1004、密鑰對存儲模塊1006及公鑰發(fā)送模塊 1008 ο
[0152]公鑰請求接收模塊1002用于接收所述客戶端發(fā)送的加密公鑰請求，所述加密公鑰請求包含所述客戶端的設備號。
[0153]密鑰對生成模塊1004用于為所述客戶端生成一對密鑰對。
[0154]密鑰對存儲模塊1006用于以所述客戶端的設備號為緩存密鑰，存儲所述密鑰對，并設置存儲失效時間。
[0155]公鑰發(fā)送模塊1008用于將所述密鑰對中的公鑰返回給所述客戶端。
[0156]在一些實施例中，還包括:公鑰加密模塊1010，用于以所述客戶端的設備號為密鑰，對所述密鑰對中的公鑰采用對稱加密方式進行加密;所述公鑰發(fā)送模塊1008還用于將加密后的所述密鑰對中的公鑰返回給所述客戶端。
[0157]需要注意的是，上述附圖中所示的框圖是功能實體，不一定必須與物理或邏輯上獨立的實體相對應?？梢圆捎密浖问絹韺崿F(xiàn)這些功能實體，或在一個或多個硬件模塊或集成電路中實現(xiàn)這些功能實體，或在不同網(wǎng)絡和/或處理器裝置和/或微控制器裝置中實現(xiàn)這些功能實體。
[0158]通過以上的實施方式的描述，本領(lǐng)域的技術(shù)人員易于理解，這里描述的示例實施方式可以通過軟件實現(xiàn)，也可以通過軟件結(jié)合必要的硬件的方式來實現(xiàn)。因此，根據(jù)本發(fā)明實施方式的技術(shù)方案可以以軟件產(chǎn)品的形式體現(xiàn)出來，該軟件產(chǎn)品可以存儲在一個非易失性存儲介質(zhì)(可以是CD-ROM，U盤，移動硬盤等)中或網(wǎng)絡上，包括若干指令以使得一臺計算設備(可以是個人計算機、服務器、移動終端、或者網(wǎng)絡設備等)執(zhí)行根據(jù)本發(fā)明實施方式的方法。
[0159]以上具體地示出和描述了本發(fā)明的示例性實施方式。應可理解的是，本發(fā)明不限于這里描述的詳細結(jié)構(gòu)、設置方式或?qū)崿F(xiàn)方法;相反，本發(fā)明意圖涵蓋包含在所附權(quán)利要求的精神和范圍內(nèi)的各種修改和等效設置。
【主權(quán)項】
1.一種基于HTTP接口的加解密方法，適用于客戶端，其特征在于，包括: 當需要向服務器獲取數(shù)據(jù)時，確定是否存儲了 API列表信息； 當存儲有所述API列表信息時，從所述API列表信息中獲取待訪問API的API訪問名；以及 向所述服務器發(fā)送用于獲取數(shù)據(jù)的HTTP請求； 其中，所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文； 所述API列表信息包括至少一個API的名字及對應的API訪問名；每個API的所述API訪問名為根據(jù)所述客戶端的設備號對所述API的名字進行加密后的密文。2.根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括: 當沒有存儲所述API列表信息時，向所述服務器發(fā)送HTTP接口API列表請求；以及 接收并存儲所述服務器返回的所述API列表信息； 其中，所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號;所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文。3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于，每個API的所述API訪問名為根據(jù)所述客戶端的設備號生成隨機數(shù)、并以所述隨機數(shù)作為密鑰對所述API的名字采用對稱加密方式進行加密后的密文。4.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文;所述方法還包括: 當確定沒有存儲在所述非對稱加密方式中使用的加密公鑰時，向所述服務器發(fā)送加密公鑰請求；以及 接收并存儲從所述服務器接收的所述加密公鑰； 其中，所述加密公鑰為采用對稱加密方式加密后的密文，且在所述對稱加密方式中使用的密鑰為所述客戶端的設備號。5.一種基于HTTP接口的加解密方法，適用于服務器，其特征在于，包括: 接收客戶端發(fā)送的HTTP請求，其中所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述待訪問API的API訪問名為根據(jù)所述客戶端的設備號對所述待訪問API的名字進行加密后的密文； 從所述HTTP請求中獲取所述客戶端的設備號； 對所述第一請求內(nèi)容進行解密，并確定對所述第一請求內(nèi)容是否解密成功； 當對所述第一請求內(nèi)容解密成功時，根據(jù)獲取的所述客戶端的設備號，對所述待訪問API的API訪問名進行解密，并確定對所述待訪問API的API訪問名是否解密成功；以及 當對所述待訪問API的API訪問名解密成功時，根據(jù)解密后得到的所述待訪問API的名字，獲取所述待訪問API的地址；根據(jù)所述待訪問API的地址，獲得所述HTTP請求的響應結(jié)果;并將所述響應結(jié)果返回給所述客戶端。6.根據(jù)權(quán)利要求5所述的方法，其特征在于，還包括: 接收所述客戶端發(fā)送的HTTP接口 API列表請求，其中所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號;所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文； 從所述HTTP接口 API列表請求中獲取所述客戶端的設備號； 對所述第二請求內(nèi)容進行解密，并確定對所述第二請求內(nèi)容是否解密成功； 當對所述第二請求內(nèi)容解密成功時，根據(jù)所述客戶端的設備號，對存儲的API列表中的每個API的名字進行加密，分別獲得其對應的API訪問名；以及 將由每個API的名字及其對應的所述API訪問名組成的API列表信息返回給所述客戶端。7.根據(jù)權(quán)利要求6所述的方法，其特征在于，根據(jù)所述客戶端的設備號，對存儲的API列表中的每個API的名字進行加密，分別獲得其對應的API訪問名包括: 根據(jù)所述客戶端的設備號生成隨機數(shù)； 以所述隨機數(shù)為密鑰，對所述API列表中的每個API的名字以對稱加密方式進行加密，以分別獲得其對應的所述API訪問名；以及 以所述客戶端的設備號為緩存密鑰，存儲所述隨機數(shù)。8.根據(jù)權(quán)利要求6或7所述的方法，其特征在于，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文;所述方法還包括: 當確定用于所述非對稱加密方式的所述客戶端的設備號對應的密鑰對失效時，或者當對所述第一請求內(nèi)容解密失敗時，或者當對所述待訪問API的API訪問名解密失敗時，或者當對所述第二請求內(nèi)容解密失敗時，向所述客戶端返回密鑰錯誤響應，以使所述客戶端清理存儲的所述API列表信息及所述密鑰對中的公鑰。9.根據(jù)權(quán)利要求5所述的方法，其特征在于，還包括: 接收所述客戶端發(fā)送的加密公鑰請求，所述加密公鑰請求包含所述客戶端的設備號； 為所述客戶端生成一對密鑰對； 以所述客戶端的設備號為緩存密鑰，存儲所述密鑰對，并設置存儲失效時間； 以所述客戶端的設備號為密鑰，對所述密鑰對中的公鑰采用對稱加密方式進行加密；以及 將加密后的所述密鑰對中的公鑰返回給所述客戶端。10.一種基于HTTP接口的加解密裝置，適用于客戶端，其特征在于，包括: 存儲確定模塊，用于當需要向服務器獲取數(shù)據(jù)時，確定是否存儲了 API列表信息； 訪問名獲取模塊，用于當所述存儲確定模塊確定存儲有所述API列表信息時，從所述API列表信息中獲取待訪問API的API訪問名；以及HTTP請求發(fā)送模塊，用于向所述服務器發(fā)送用于獲取數(shù)據(jù)的HTTP請求； 其中，所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文； 所述API列表信息包括至少一個API的名字及對應的API訪問名；每個API的所述API訪問名為根據(jù)所述客戶端的設備號對所述API的名字進行加密后的密文。11.根據(jù)權(quán)利要求10所述的裝置，其特征在于，還包括: API請求發(fā)送模塊，用于當所述存儲確定模塊確定沒有存儲所述API列表信息時，向所述服務器發(fā)送HTTP接口 API列表請求；以及 API列表接收模塊，用于接收并存儲所述服務器返回的所述API列表信息； 其中，所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號;所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文。12.根據(jù)權(quán)利要求10或11所述的裝置，其特征在于，每個API的所述API訪問名為根據(jù)所述客戶端的設備號生成隨機數(shù)、并以所述隨機數(shù)作為密鑰對所述API的名字采用對稱加密方式進行加密后的密文。13.根據(jù)權(quán)利要求11所述的裝置，其特征在于，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文;所述裝置還包括: 公鑰請求發(fā)送模塊，用于當確定沒有存儲在所述非對稱加密方式中使用的加密公鑰時，向所述服務器發(fā)送加密公鑰請求；以及 公鑰接收模塊，用于接收并存儲從所述服務器接收的所述加密公鑰； 其中，所述加密公鑰為采用對稱加密方式加密后的密文，且在所述對稱加密方式中使用的密鑰為所述客戶端的設備號。14.一種基于HTTP接口的加解密裝置，適用于服務器，其特征在于，包括: HTTP請求接收模塊，用于接收客戶端發(fā)送的HTTP請求，其中所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述待訪問API的API訪問名為根據(jù)所述客戶端的設備號對所述待訪問API的名字進行加密后的密文； 第一設備號獲取模塊，用于從所述HTTP請求中獲取所述客戶端的設備號； 第一請求解密模塊，用于對所述第一請求內(nèi)容進行解密，并確定對所述第一請求內(nèi)容是否解密成功； 訪問名解密模塊，用于當所述第一請求解密模塊確定對所述第一請求內(nèi)容解密成功時，根據(jù)獲取的所述客戶端的設備號，對所述待訪問API的API訪問名進行解密，并確定對所述待訪問API的API訪問名是否解密成功；以及 HTTP請求處理模塊，用于當所述訪問名解密模塊確定對所述待訪問API的API訪問名解密成功時，根據(jù)解密后得到的所述待訪問API的名字，獲取所述待訪問API的地址;根據(jù)所述待訪問API的地址，獲得所述HTTP請求的響應結(jié)果;并將所述響應結(jié)果返回給所述客戶端。15.根據(jù)權(quán)利要求14所述的裝置，其特征在于，還包括: API請求接收模塊，用于接收所述客戶端發(fā)送的HTTP接口 API列表請求，其中所述HTTP接口 API列表請求包括:第二請求內(nèi)容及所述客戶端的設備號;所述第二請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文； 第二設備號讀取模塊，用于從所述HTTP接口 API列表請求中獲取所述客戶端的設備號；第二請求解密模塊，用于對所述第二請求內(nèi)容進行解密，并確定對所述第二請求內(nèi)容是否解密成功； API列表生成模塊，用于當所述第二請求解密模塊確定對所述第二請求內(nèi)容解密成功時，根據(jù)所述客戶端的設備號，對存儲的API列表中的每個API的名字進行加密，分別獲得其對應的API訪問名；以及 API列表發(fā)送模塊，用于將由每個API的名字及其對應的所述API訪問名組成的API列表信息返回給所述客戶端。16.根據(jù)權(quán)利要求15所述的裝置，其特征在于，所述API列表生成模塊包括: 隨機數(shù)生成子模塊，用于根據(jù)所述客戶端的設備號生成隨機數(shù)； API加密子模塊，用于以所述隨機數(shù)為密鑰，對所述API列表中的每個API的名字以對稱加密方式進行加密，以分別獲得其對應的所述API訪問名；以及 隨機數(shù)存儲子模塊，用于以所述客戶端的設備號為緩存密鑰，存儲所述隨機數(shù)。17.根據(jù)權(quán)利要求15或16所述的裝置，其特征在于，所述第一請求內(nèi)容和所述第二請求內(nèi)容為采用非對稱加密方式加密后的密文;所述裝置還包括: 密鑰錯誤響應模塊，用于當確定用于所述非對稱加密方式的所述客戶端的設備號對應的密鑰對失效時，或者當所述第一請求解密模塊確定對所述第一請求內(nèi)容解密失敗時，或者當所述訪問名解密模塊確定對所述待訪問API的API訪問名解密失敗時，或者當?shù)诙埱蠼饷苣K確定對所述第二請求內(nèi)容解密失敗時，向所述客戶端返回密鑰錯誤響應，以使所述客戶端清理存儲的所述API列表信息及所述密鑰對中的公鑰。18.根據(jù)權(quán)利要求14所述的裝置，其特征在于，還包括: 公鑰請求接收模塊，用于接收所述客戶端發(fā)送的加密公鑰請求，所述加密公鑰請求包含所述客戶端的設備號； 密鑰對生成模塊，用于為所述客戶端生成一對密鑰對； 密鑰對存儲模塊，用于以所述客戶端的設備號為緩存密鑰，存儲所述密鑰對，并設置存儲失效時間； 公鑰加密模塊，用于以所述客戶端的設備號為密鑰，對所述密鑰對中的公鑰采用對稱加密方式進行加密；以及 公鑰發(fā)送模塊，用于將加密后的所述密鑰對中的公鑰返回給所述客戶端。19.一種基于HTTP接口的加解密系統(tǒng)，適用于客戶端，其特征在于，包括: 處理器；以及 存儲器，用于存儲所述處理器的可執(zhí)行指令； 其中所述處理器配置為經(jīng)由執(zhí)行所述可執(zhí)行指令來執(zhí)行以下操作: 當需要向服務器獲取數(shù)據(jù)時，確定是否存儲了 API列表信息； 當存儲有所述API列表信息時，從所述API列表信息中獲取待訪問API的API訪問名；以及 向所述服務器發(fā)送用于獲取數(shù)據(jù)的HTTP請求； 其中，所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文； 所述API列表信息包括至少一個API的名字及對應的API訪問名；每個API的所述API訪問名為根據(jù)所述客戶端的設備號對所述API的名字進行加密后的密文。20.一種基于HTTP接口的加解密系統(tǒng)，適用于服務器，其特征在于，包括: 處理器；以及 存儲器，用于存儲所述處理器的可執(zhí)行指令； 其中所述處理器配置為經(jīng)由執(zhí)行所述可執(zhí)行指令來執(zhí)行以下操作: 接收客戶端發(fā)送的HTTP請求，其中所述HTTP請求包括:含有所述待訪問API的API訪問名的第一請求內(nèi)容及所述客戶端的設備號;所述第一請求內(nèi)容為加密后的密文，所述客戶端的設備號為明文;所述待訪問API的API訪問名為根據(jù)所述客戶端的設備號對所述待訪問API的名字進行加密后的密文； 從所述HTTP請求中獲取所述客戶端的設備號； 對所述第一請求內(nèi)容進行解密，并確定對所述第一請求內(nèi)容是否解密成功； 當對所述第一請求內(nèi)容解密成功時，根據(jù)獲取的所述客戶端的設備號，對所述待訪問API的API訪問名進行解密，并確定對所述待訪問API的API訪問名是否解密成功；以及 當對所述待訪問API的API訪問名解密成功時，根據(jù)解密后得到的所述待訪問API的名字，獲取所述待訪問API的地址；根據(jù)所述待訪問API的地址，獲得所述HTTP請求的響應結(jié)果;并將所述響應結(jié)果返回給所述客戶端。
【文檔編號】H04L9/08GK106060037SQ201610366145
【公開日】2016年10月26日
【申請日】2016年5月27日
【發(fā)明人】莫文, 熊健南, 畢磊
【申請人】北京京東尚科信息技術(shù)有限公司, 北京京東世紀貿(mào)易有限公司