不使用https的數(shù)據(jù)安全傳輸方法及系統(tǒng)、客戶端和服務端的制作方法
【專利說明】不使用HTTPS的數(shù)據(jù)安全傳輸方法及系統(tǒng)、客戶端和服務
2.LU
?而
技術領域
[0001]本申請涉及廣域物聯(lián)網(wǎng)組網(wǎng)技術領域，具體涉及一種數(shù)據(jù)安全傳輸方法和系統(tǒng)、及其涉及的客戶端和服務端。
【背景技術】
[0002]物聯(lián)網(wǎng)是指按約定的協(xié)議，把物品與互聯(lián)網(wǎng)連接起來，進行信息交換和通信，以實現(xiàn)智能化識別、定位、跟蹤、監(jiān)控和管理的一種網(wǎng)絡。物聯(lián)網(wǎng)的典型應用之一是車輛管理系統(tǒng)，尤其是針對車輛卡(包括基于電子標簽的IC卡)的管理系統(tǒng)。目前，車輛卡管理系統(tǒng)使用傳統(tǒng)的三層架構方案，由數(shù)據(jù)訪問層、業(yè)務邏輯層、表示層組成，如圖1所示。業(yè)務邏輯層使用Webserver建立后臺服務器，表示層通過訪問Webserver提供的接口實現(xiàn)業(yè)務邏輯數(shù)據(jù)傳輸。
[0003]在車輛卡管理系統(tǒng)中，終端客戶的種類不唯一，不同業(yè)務對數(shù)據(jù)保密級別的要求也不一樣，一些特殊的數(shù)據(jù)需要進行加密傳輸，傳統(tǒng)的處理方法是使用HTTPS協(xié)議(HyperText Transfer Protocol over Secure Socket Layer，基于安全套接字層的超文本傳輸協(xié)議)來進行數(shù)據(jù)的安全傳輸控制。對于車輛卡系統(tǒng)，使用HTTPS協(xié)議存在以下的不足:
[0004]1、服務器必須從CA (Certificate Authority，證書授權中心)申請一個用于證明服務器用途類型的證書，免費證書很少，通常需要交費；
[0005]2、HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，認證過程復雜，單次認證過程比較漫長，一般用于銀行、交易支付方面；
[0006]3、使用HTTPS協(xié)議的服務端和客戶端之間的所有通訊都是加密的，無法定制加密數(shù)據(jù)段，如果需要定制加密接口，則需要使用兩套協(xié)議方案，一套使用HTTPS傳輸協(xié)議，一套使用HTTP傳輸協(xié)議，不便于維護。

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

[0007]本申請?zhí)峁┮环N適用于車輛卡管理系統(tǒng)的數(shù)據(jù)安全傳輸方法及系統(tǒng)，該方法和系統(tǒng)也可以適用于廣域物聯(lián)網(wǎng)的其他應用。
[0008]根據(jù)本申請的第一方面，本申請?zhí)峁┮环N不使用基于安全套接字層的超文本傳輸協(xié)議(HTTPS)的數(shù)據(jù)安全傳輸方法，該方法包括以下步驟:
[0009]注冊步驟:服務端在本地創(chuàng)建證書授權中心(CA)，并向相連的客戶端頒發(fā)用戶證書，所述用戶證書用作所述客戶端登錄所述服務端的登錄憑證；
[0010]登錄步驟:所述服務端在收到所述客戶端的登錄信息后，根據(jù)所述登錄憑證分配密鑰，并將所述密鑰返回給所述客戶端；
[0011]加解密步驟:所述服務端根據(jù)所述密鑰加密或解密所述客戶端發(fā)來的數(shù)據(jù)信息。
[0012]進一步地，該方法的所述登錄步驟還包括生成識別步驟，在所述生成識別子步驟中，所述服務端根據(jù)所述登錄憑證生成用戶識別碼，并將所述用戶識別碼返回給所述客戶端；所述加解密步驟還包括用戶識別步驟，在所述用戶識別步驟中，所述服務端在接收到所述客戶端發(fā)送的數(shù)據(jù)信息后，根據(jù)所述用戶識別碼確定所述數(shù)據(jù)信息對應的客戶端，并響應所述對應的客戶端。
[0013]進一步地，該方法還包括接口定制步驟:所述服務端根據(jù)所述客戶端的類型和業(yè)務功能提供安全接口信息，并向所述客戶端公布所述安全接口信息，所述安全接口信息用于指示需要加解密操作的接口 ；所述服務端根據(jù)所述客戶端發(fā)送來的攜帶有與安全接口信息相關內(nèi)容的數(shù)據(jù)信息，結合所述安全接口信息確定關于待傳輸數(shù)據(jù)的加解密操作。
[0014]進一步地，在該方法中，傳輸于所述服務端和所述客戶端之間的數(shù)據(jù)的格式為JSON數(shù)據(jù)交換格式；和/或，所述服務端和所述客戶端之間的加密數(shù)據(jù)使用BASE64進行編碼后再傳輸。
[0015]根據(jù)本申請的第二方面，本申請?zhí)峁┮环N使用如上所述方法實現(xiàn)的不使用HTTPS的數(shù)據(jù)安全傳輸系統(tǒng)。
[0016]根據(jù)本申請的第三方面，本申請?zhí)峁┮环N用于如上所述方法的客戶端。
[0017]根據(jù)本申請的第四方面，本申請?zhí)峁┮环N用于如上所述方法的服務端。
[0018]本申請的有益效果是:通過服務端自己創(chuàng)建CA，所有用戶證書由該CA頒發(fā)，不需要額外付費購買第三方的CA ;服務端在收到登錄信息后，分配密鑰給客戶端，這樣客戶端可以使用該密鑰對數(shù)據(jù)信息加密(解密)操作，而服務端可以使用該密鑰對客戶端發(fā)送來的數(shù)據(jù)信息進行解密(加密)操作，從而，在不使用HTTPS協(xié)議進行傳輸時，也能安全傳輸數(shù)據(jù)，實現(xiàn)了數(shù)據(jù)傳輸?shù)碾p向認證。
【附圖說明】
[0019]圖1為車輛卡管理系統(tǒng)的三層架構方案示意圖；
[0020]圖2示出了本申請一種實施方式中的密鑰生成過程，其實際上也示出了客戶端登錄服務端時二者的交互；
[0021]圖3至圖6示出了本申請一種實施方式中的安全接口數(shù)據(jù)控制流程，其實際上也示出了客戶端與服務端進行業(yè)務數(shù)據(jù)傳輸時二者的交互；
[0022]圖7示出了本申請一種實施方式用于車輛卡管理系統(tǒng)中的部分接口列表；
[0023]圖8示出了本申請一種實施方式中客戶端和服務端之間的拓撲示意圖。
【具體實施方式】
[0024]本申請仍以車輛卡管理系統(tǒng)為例，對本申請?zhí)岢龅牟皇褂肏TTPS的數(shù)據(jù)安全傳輸方法及系統(tǒng)以及其涉及的客戶端和服務端進行描述。可以理解的是，該方法和系統(tǒng)及其涉及的客戶端和服務端也可以應用于廣域物聯(lián)網(wǎng)的其它應用中。
[0025]對于車輛卡管理系統(tǒng)，需要考慮穩(wěn)定性、安全性和易用性。因此，本申請在設計該車輛卡管理系統(tǒng)的方案中，對傳輸數(shù)據(jù)進行了多方面的考慮，例如引入了服務端自身認證的證書，來實現(xiàn)數(shù)據(jù)雙向認證機制；又例如傳輸?shù)挠脩魯?shù)據(jù)使用對稱加密技術，這樣相比采用HTTPS協(xié)議的傳輸可以盡可能地提高效率；再例如還可以使用用戶識別碼，接口數(shù)據(jù)不包含用戶信息內(nèi)容，從而可以對用戶信息給予保密；又例如還可以使接口參數(shù)和返回數(shù)據(jù)為字符串，從而傳輸數(shù)據(jù)與數(shù)據(jù)類型無關；再例如還可定制化接口數(shù)據(jù)傳輸?shù)陌踩刂?，即定制是否需要加密傳輸?shù)據(jù)。
[0026]因此，在本申請的一種實施方式中，提出了不使用HTTPS的數(shù)據(jù)安全傳輸方法，該方法包括注冊步驟、登錄步驟和加解密步驟。在注冊步驟中，服務端在本地創(chuàng)建證書授權中心，并向相連的客戶端頒發(fā)用戶證書，用戶證書用作客戶端登錄所述服務端的登錄憑證；在登錄步驟中，服務端在收到客戶端的登錄信息后，根據(jù)登錄憑證分配密鑰，并將密鑰返回給客戶端；在加解密步驟中，服務端根據(jù)密鑰加密或解密客戶端發(fā)來的數(shù)據(jù)信息。
[0027]具體地，對于注冊步驟，首先服務端自己創(chuàng)建證書授權中心(CA)，并在接收到所述客戶端的注冊信息時，向客戶端頒發(fā)CA認證的用戶證書，并保存客戶端相關的信息及其對應的用戶證書，一般地，客戶端相關的信息至少包括該客戶端的用戶名和密碼。
[0028]對于登錄步驟，當服務端接收客戶端發(fā)送來的登錄信息，通常登錄信息包括客戶端的用戶名和密碼，在本實施方式中，該密碼為使用客戶端的用戶證書加密后的密文；然后，服務端根據(jù)用戶名取得對應的用戶證書，使用用戶證書解密密文得到密碼，然后隨機產(chǎn)生密鑰，保存密鑰，并將密鑰返回給客戶端。當然，本步驟或者后續(xù)一些步驟中還可以涉及一些已知的技術手段，例如，在解密得到密碼后，服務端將該密碼和用戶名與服務端事先存儲的客戶端相關的信息進行校驗，如果校驗通過，則繼續(xù)后續(xù)步驟如產(chǎn)生密鑰等，如果校驗不通過，則可以向客戶端發(fā)送用戶名和密碼不匹配之類的提示信息。
[0029]在另一種實施方式中，除了具有上述實施方式的功能步驟外，登錄步驟還可以包括生成識別步驟，對應地，加解密步驟還可以包括用戶識別步驟。在生成識別子步驟中，服務端根據(jù)登錄憑證，生成用戶識別碼(也可以稱之為用戶登錄校驗碼)，并將用戶識別碼返回給客戶端；在用戶識別步驟中，服務端在接收到客戶端發(fā)送的數(shù)據(jù)信息后，根據(jù)用戶識別碼確定數(shù)據(jù)信息對應的客戶端，并響應對應的客戶端。
[0030]具體地，在生成識別步驟中，服務端在接收到客戶端發(fā)送來的登錄信息后，根據(jù)客戶端的登錄憑證隨機產(chǎn)生用戶識別碼，保存用戶識別碼，并將用戶識別碼返回給客戶端；而在用戶識別步驟中，服務端在確定出數(shù)據(jù)信息對應的客戶端后，獲得對應的客戶端的密鑰。
[0031]在又一種實施方式中，除了具有上述各實施方式的功能步驟外，本申請的不使用HTTPS協(xié)議的數(shù)據(jù)安全傳輸方法還可以包括接口定制步驟:服務端根據(jù)客戶端的類型和業(yè)務功能提供安全接口信息，并向客戶端公布安全接口信息，安全接口信息用于指示需要加解密操作的接口 ；當服務端接收到客戶端發(fā)送來的攜帶有與安全接口信息相關內(nèi)容的數(shù)據(jù)信息，結合該安全接口信息確定關于待傳輸數(shù)據(jù)的加解密操作。一種實施例中，安全接口信息包括安全接口列表，該安全接口列表中登記有需要對傳輸數(shù)據(jù)進行加解密操作的接口 ；另一種實施例中，安全接口信息包括帶有安全參數(shù)值的接口函數(shù)，該安全參數(shù)值用于表征接口安全的級別。
[0032]本申請還提供一種實施方式，其除了具有上述各實施方式的功能步驟外