基于混合加密API算法對地震數(shù)據(jù)安全傳輸?shù)难芯?/h1>
2022-08-03 08:05吳凌杰嚴(yán)俊峰
華南地震 2022年2期
吳凌杰，孟 真，嚴(yán)俊峰
（浙江省地震局，杭州 310013）
0 引言
地震科學(xué)數(shù)據(jù)涵蓋學(xué)科多、數(shù)據(jù)體量大、時間跨度長、動態(tài)性強(qiáng)和數(shù)據(jù)結(jié)構(gòu)異構(gòu)等特點(diǎn)，導(dǎo)致現(xiàn)存系統(tǒng)在體量、功能和性能方面難以滿足數(shù)據(jù)安全共享需求[1-2]。目前，應(yīng)用程序接口（Application Programming Interface，API）做為移動設(shè)計、云計算、物聯(lián)網(wǎng)、大數(shù)據(jù)及社交網(wǎng)絡(luò)等應(yīng)用數(shù)據(jù)交互的一種核心技術(shù)[3]，為地震數(shù)據(jù)傳輸和共享提供了創(chuàng)新性和顛覆性的解決辦法。但是API的開放屬性導(dǎo)致其很容易出現(xiàn)：用戶賬號密碼被截獲、表單數(shù)據(jù)被篡改和業(yè)務(wù)數(shù)據(jù)泄露等問題，極大地威脅到使用API 傳輸?shù)卣饠?shù)據(jù)的安全性[4-6]。因此，如何使用API安全傳輸?shù)卣饠?shù)據(jù)是當(dāng)下亟需研究的一項(xiàng)課題。
目前保障API調(diào)用時數(shù)據(jù)安全的常用方案有通信使用HTTPS 協(xié)議、請求簽名、身份確認(rèn)機(jī)制和對請求響應(yīng)加解密等。HTTPS 協(xié)議[7-8]的主要作用是確認(rèn)雙方的身份和建立安全通道，保障數(shù)據(jù)的安全傳輸。但是HTTPS 不能防中間人攻擊，使用成本高，占用服務(wù)器資源多而且響應(yīng)速度慢。對于傳輸大體量數(shù)據(jù)和震情發(fā)生后的緊急情況，HTTPS并不是最優(yōu)選擇。姜建武等[9]使用雙重簽名驗(yàn)證、請求體加密等方式來加固用戶數(shù)據(jù)傳輸安全性。請求簽名在一定程度上可以保證數(shù)據(jù)傳輸安全性，但是在數(shù)據(jù)傳輸前需要提前約定密鑰。由于地震災(zāi)害的突發(fā)性和不可預(yù)測性，應(yīng)急情況下幾乎沒有條件在數(shù)據(jù)傳輸前就約定好密鑰或者輸入密鑰。殷佳庭等[10]使用請求和響應(yīng)均加解密的辦法，請求前數(shù)據(jù)先使用AES 算法加密，接收數(shù)據(jù)后再用AES 密鑰解密，由于AES 密鑰的唯一性，密鑰需要由服務(wù)端跟客戶端事先約定，同樣在地震應(yīng)急場景中一定的局限性。
綜上所述，針對地震數(shù)據(jù)體量大、對響應(yīng)速度要求高以及無法事先交換密鑰的應(yīng)急需求，本文基于RSA和AES兩種加密算法結(jié)合API運(yùn)行機(jī)制提出了一種混合加密API 算法，并將混合加密API 算法與不加密API 進(jìn)行對比，探索兩者在數(shù)據(jù)加密、API 性能和資源消耗等方面的差異并對差異產(chǎn)生的原因進(jìn)行分析解釋。
1 加密算法介紹
當(dāng)前密碼學(xué)體系中的加密算法一般分為對稱加密算法和非對稱加密算法兩種[11]。對稱加密算法就是使用相同的密鑰對數(shù)據(jù)進(jìn)行加解密。非對稱加密算法是指加解密使用不同的密鑰，通常此類算法有兩個密鑰，為公鑰和私鑰。發(fā)送方使用接收方的公鑰對明文進(jìn)行加密，接收方使用自己的私鑰進(jìn)行解密獲得明文信息。公鑰是可以對外界開放的，私鑰只能由持有人知道。
1.1 AES算法
AES 算法是當(dāng)前使用最多的分組對稱加密算法，分組指在加密和解密時把明文分成長度相等的幾組。在AES 的標(biāo)準(zhǔn)規(guī)范中，分組長度固定為128位。密鑰的長度可以使用128 位、192 位或256 位，不同的密鑰長度對應(yīng)的加密輪數(shù)也不同[12]。差異如表1所示。本文使用128位密鑰加密。
表1 AES密鑰長度和加密輪數(shù)Table 1 Key length and encryption round of AES
AES加密過程涉及到四個環(huán)節(jié)，分別為輪密鑰加、字節(jié)代換、行位移和列混淆。輪密鑰加是將128 位的密鑰同狀態(tài)矩陣中的數(shù)據(jù)進(jìn)行逐位異或操作。字節(jié)代換采用的S 盒是16×16 字節(jié)的二維表，所有元素在整個加密過程中保持定值。行位移是做一個簡單的循環(huán)移位操作。列混淆是將移位后的狀態(tài)矩陣與固定矩陣相乘。
1.2 RSA算法
RSA加密算法是當(dāng)前較為流行的一種公鑰密碼算法。算法的核心是運(yùn)用一種產(chǎn)生復(fù)雜的、偽隨機(jī)數(shù)據(jù)序列的模運(yùn)算[13]。RSA算法是建立在“大數(shù)分解和素數(shù)檢測”的理論基礎(chǔ)上，兩個大素數(shù)相乘在計算機(jī)上很容易實(shí)現(xiàn)，但是將該乘積分解為兩個大素數(shù)因子的計算量卻非常大。RSA算法需要?dú)W拉函數(shù)、歐拉定理和模反元素等基礎(chǔ)數(shù)學(xué)知識。算法生成密鑰的過程主要分為三步：①隨意生成兩個大素數(shù)p，q（p≠q），令n=p×q；②根據(jù)歐拉函數(shù)性質(zhì)可得r=φ(n)= φ( p)φ(q)=( p - 1)(q - 1)；③隨機(jī)選擇一個小于r 的整數(shù)e，且e 與r 互為素數(shù)。根據(jù)模反元素兩個正整數(shù)e 與r 互素，那么一定可以找到整數(shù)d，使得ed-1 被r 除，可求得e 關(guān)于r 的模反元素d。可得公鑰為（n，e），（n，d）是私鑰。最后銷毀p，q。
得到公鑰后，需要對明文信息m 進(jìn)行加密，將公鑰和明文信息帶入式子m∧e=c（mod n），計算得到的c即為密文。解密時將密鑰跟密文代入式子c∧d=m（mod n），即可得到明文m。
1.3 混合加密API算法
AES 算法將數(shù)據(jù)和密鑰按字節(jié)來處理，加解密運(yùn)算速度快，適用于大批量數(shù)據(jù)的處理。但由于很難解決密鑰分發(fā)的安全性和數(shù)字簽名等問題，用于API 加密傳輸時，數(shù)據(jù)的安全性較弱[14]。而RSA 算法使用公鑰加密私鑰解密，公鑰可以向外界公布，只要私鑰不泄露，很大程度能保障數(shù)據(jù)的安全性。但是RSA 算法的短板在于加解密都是進(jìn)行大數(shù)計算，處理大體量數(shù)據(jù)會增加運(yùn)算時間和設(shè)備性能消耗，用于API加密傳輸會嚴(yán)重影響數(shù)據(jù)傳輸效率[15]。為了解決AES 算法密鑰的短板，同時彌補(bǔ)RSA 算法處理速度慢的缺點(diǎn)。本文利用AES 算法運(yùn)算速度快的特性來處理需要傳輸?shù)臄?shù)據(jù)，使用RSA 算法密鑰配置特性高的特點(diǎn)配置AES密鑰，同時結(jié)合通信網(wǎng)絡(luò)的運(yùn)行機(jī)制[16]，提出了一種混合加密API算法。
算法具體流程為：當(dāng)客戶端啟動時，發(fā)送請求到服務(wù)端，服務(wù)端用RSA 算法生成公鑰publickeys和私鑰privatekeys，并將publickeys返回給客戶端?？蛻舳四玫椒?wù)端返回的公鑰后，用RSA 算法生成公鑰publickeyb和私鑰privatekeyb，并把publickeyb交給服務(wù)端，此時前后端通信建立。當(dāng)客戶端需要給服務(wù)端發(fā)送數(shù)據(jù)時，客戶端先生成128 位密鑰key，然后把需要發(fā)送的數(shù)據(jù)和key 用AES 算法加密，key 再用publickeyb加密成aeskey后和密文一并傳輸給服務(wù)端，服務(wù)端給客戶端發(fā)送數(shù)據(jù)亦是如此。在服務(wù)端與客戶端建立通訊后，前后端生成的publickey 和privatekey 不再改變，key 則會在每次傳輸數(shù)據(jù)前重新生成。服務(wù)端與客戶端通信建立流程圖如下圖1所示，數(shù)據(jù)加密傳輸流程示意圖如圖2所示。
圖1 服務(wù)端與客戶端通信示意圖Fig.1 Schematic diagram of communication between server and client
2 數(shù)據(jù)來源
地震監(jiān)測是地震學(xué)科的重要基礎(chǔ)與核心業(yè)務(wù)。由于地球內(nèi)部的不可入性，目前只能在地表建設(shè)大量的觀測臺站來監(jiān)測地震情況，臺站產(chǎn)生的數(shù)據(jù)再通過龐大的網(wǎng)絡(luò)系統(tǒng)進(jìn)行匯聚[17]。因此地震科學(xué)數(shù)據(jù)主要來源就是臺站的基礎(chǔ)數(shù)據(jù)和觀測數(shù)據(jù)。本文選用國家地震烈度速報與預(yù)警工程中臺站監(jiān)控系統(tǒng)的臺站基礎(chǔ)數(shù)據(jù)表來驗(yàn)證算法的加密效果。臺站基礎(chǔ)數(shù)據(jù)表結(jié)構(gòu)見表2，其中臺站的位置和通信數(shù)據(jù)等都為敏感數(shù)據(jù)。同時選用浙江省地球物理臺網(wǎng)海寧臺垂直擺傾斜觀測系統(tǒng)東西分量24 h的記錄量作為測試API性能數(shù)據(jù)，該系統(tǒng)每秒鐘記錄一次數(shù)據(jù)，一天的數(shù)據(jù)量會打包在一起。
圖2 數(shù)據(jù)加密傳輸流程圖Fig.2 Flow chart of data encryption transmission process
3 實(shí)驗(yàn)結(jié)果與分析
3.1 加密性驗(yàn)證
本文使用JAVA 語言和Springboot 框架實(shí)現(xiàn)混合加密API 和不加密API 的功能。為了驗(yàn)證混合加密API 能否在實(shí)際業(yè)務(wù)中有效的加密和傳輸數(shù)據(jù)。本文設(shè)置了如下交互方式，當(dāng)服務(wù)端與客戶端建立通信后，客戶端以HTTP 協(xié)議發(fā)起POST 請求且請求攜帶參數(shù)為data="stationimf ormation"時，服務(wù)端以JSON 格式的臺站敏感數(shù)據(jù)響應(yīng)。實(shí)驗(yàn)過程中通過抓包軟件抓取加密和不加密API請求和響應(yīng)的數(shù)據(jù)。未加密API 抓包數(shù)據(jù)如圖3 所示，加密API抓包數(shù)據(jù)如圖4所示。
表2 臺站基礎(chǔ)數(shù)據(jù)表Table 2 Basic data of station
圖3 未加密API數(shù)據(jù)抓包圖Fig.3 Unencrypted API data packet capture diagram
圖4 加密API數(shù)據(jù)抓包圖Fig.4 Encrypted API data packet capture diagram
圖中請求體的參數(shù)Name 和Value 分別表示客戶端POST請求攜帶的參數(shù)名稱和值，JSON為客戶端返回的數(shù)據(jù)。從圖3 可以看出，未加密API 客戶端請求參數(shù)data 和服務(wù)端返回的JSON 數(shù)據(jù)都被抓到，臺站敏感數(shù)據(jù)一覽無余。而圖4中aesKey為使用后端公鑰加密的AES密鑰，data為請求數(shù)據(jù)，均為密文。返回的JSON 信息也為密文。在無法獲得密鑰的情況下，想要破解密文的難度非常大，很好的保護(hù)臺站敏感數(shù)據(jù)的安全性，為地震數(shù)據(jù)安全傳輸提供了可靠的保證。
3.2 接口性能測試
為了測試混合加密API在實(shí)際業(yè)務(wù)中的接口性能表現(xiàn)，本文使用由Apache 公司基于Java 開發(fā)的API 性能檢測工具Jmeter 來做測試。該軟件可以模擬用戶對API 發(fā)起請求和接受響應(yīng)，且可以編寫Java腳本對數(shù)據(jù)進(jìn)行加解密操作。由于Jmeter在做批量測試時，無法先從服務(wù)端獲取公鑰，因此在編寫Jmeter 測試腳本時，需先將后端公鑰寫進(jìn)腳本，保證首次發(fā)起請求時客戶端與服務(wù)端已建立通信。
同樣以未加密API作為對照組進(jìn)行測試，測試使用Jmeter 軟件模擬用戶以HTTP 協(xié)議對API 發(fā)起1 進(jìn)程500 次的POST 請求。發(fā)起請求時，未加密API直接將臺站觀測數(shù)據(jù)作為請求參數(shù)發(fā)送，服務(wù)端接收后原樣返回測試數(shù)據(jù)，Jmeter接收數(shù)據(jù)后完成一次請求與響應(yīng)。加密API則在發(fā)起請求前先將臺站觀測數(shù)據(jù)進(jìn)行加密，以密文作為請求參數(shù)，服務(wù)端在獲取密文進(jìn)行解密后，再將測試數(shù)據(jù)進(jìn)行加密返回給Jmeter，等到Jmeter 解密獲得明文，完成一次請求與響應(yīng)過程。為減小網(wǎng)絡(luò)因素給測試結(jié)果帶來誤差，客戶端與服務(wù)端運(yùn)行在同一子網(wǎng)內(nèi)。服務(wù)器為32 GB 內(nèi)存，2.4 GHz CPU 的深信服云服務(wù)器。未加密與混合加密API請求響應(yīng)時間圖如5 和圖6 所示。請求響應(yīng)時間是指從客戶端發(fā)送一個請求，到客戶端接收到服務(wù)器返回響應(yīng)結(jié)果時長。
圖5 未加密API請求響應(yīng)時間圖Fig.5 Request response time graph of unencrypted API
圖6 加密API請求響應(yīng)時間圖Fig.6 Request response time graph of encrypted API
從圖中可以看到，首次發(fā)起請求的響應(yīng)時間都是最長的，這是因?yàn)镠TTP 是建立在TCP 之上的，TCP 握手會占用一定時間。從第二次開始，響應(yīng)時間基本趨于穩(wěn)定。但是混合加密API 與未加密API響應(yīng)時間存在差值。于是本文統(tǒng)計了所有請求的響應(yīng)時間，如表3所示。
從表中可以看出，混合加密API運(yùn)行穩(wěn)定無失敗。加密API 平均響應(yīng)時間比未加密API 多6.97ms，在忽略網(wǎng)絡(luò)等其他影響因素的情況下，這個時間即為服務(wù)器處理加解密算法的平均時長。統(tǒng)計發(fā)現(xiàn)，90%的響應(yīng)時間差均在8ms以內(nèi)，時間差幾乎可以忽略不計。因此，混合加密API對地震數(shù)據(jù)傳輸速度產(chǎn)生的影響可以忽略不計。
由于地震系統(tǒng)有很多觀測系統(tǒng)，在匯聚傳輸不加密數(shù)據(jù)時會對服務(wù)器的性能有較高的要求，因此接口的性能消耗也是一項(xiàng)非常重要的指標(biāo)。于是本文還記錄了響應(yīng)過程中服務(wù)器的CPU 和內(nèi)存使用率分別，如圖7和圖8所示。
表3 接口響應(yīng)時間表Table 3 Response timetable of interface
圖7 未加密API運(yùn)行性能圖Fig.7 Running performance graph of unencrypted API
對比內(nèi)存使用量，兩種接口對內(nèi)存的消耗幾乎相等，因此混合加密API 對內(nèi)存的影響和消耗不大。對于CPU性能來說，未加密API運(yùn)行時CPU平均使用率約為0.71%，混合加密API 為1.92%，相差1.21%，CPU資源占用量不多。
圖8 加密API運(yùn)行性能圖Fig.8 Running performance graph of encrypted API
3.3 局限性分析
網(wǎng)絡(luò)攻防就像矛與盾，沒有絕對鋒利的矛也沒有絕對堅硬的盾。本文介紹的混合加密API算法在一定程度上保障了地震數(shù)據(jù)傳輸?shù)陌踩院头€(wěn)定性，但并不能完全阻止中間人的攻擊，只能增加中間人的攻擊成本。此外，數(shù)據(jù)安全傳輸?shù)姆桨赣泻芏喾N，安全性的提高，必然也會帶來成本、資源和時間消耗的增加。
4 結(jié)論
本文以AES 和RSA 加密算法為基礎(chǔ)，結(jié)合API運(yùn)行機(jī)制，將兩種算法優(yōu)勢互補(bǔ)取長補(bǔ)短，構(gòu)建了一種混合加密API 算法。通過與不加密API 進(jìn)行比較，分析了兩種不同地震系統(tǒng)數(shù)據(jù)，研究了混合加密API在地震數(shù)據(jù)傳輸?shù)陌踩?、穩(wěn)定性、快速性、適應(yīng)性和資源消耗方面的特點(diǎn)。研究結(jié)論主要有以下幾點(diǎn)：
（1）混合加密API 算法能有效地對API 傳輸?shù)臄?shù)據(jù)進(jìn)行加密，在一定程度上保障了地震數(shù)據(jù)的安全性。
（2）在實(shí)際業(yè)務(wù)中，無需提前交換密鑰，混合加密API算法就能高效穩(wěn)定地運(yùn)行，保障了應(yīng)急情況下地震數(shù)據(jù)的安全傳輸。
（3）混合加密API 算法對地震數(shù)據(jù)的傳輸速度不會產(chǎn)生影響。
（4）混合加密API 算法要對數(shù)據(jù)進(jìn)行加解密計算，對計算機(jī)的CPU 資源有一定的消耗，對內(nèi)存幾乎無消耗?？傮w來說，只占用了少量的服務(wù)器資源。
猜你喜歡
基于ETL技術(shù)的臺站信息同步應(yīng)用研究科技與創(chuàng)新(2021年24期)2022-01-03 地震臺站基礎(chǔ)信息完善及應(yīng)用分析科技研究·理論版(2021年20期)2021-04-20 一種適用于高鐵沿線的多臺站快速地震預(yù)警方法中小企業(yè)管理與科技·下旬刊(2021年1期)2021-03-02 神奇的公鑰密碼知識就是力量(2018年10期)2018-10-18 新時期《移動Web服務(wù)端開發(fā)》課程教學(xué)改革的研究消費(fèi)導(dǎo)刊(2018年8期)2018-05-25 一種具備干擾臺站剔除的多臺站定位方法價值工程(2018年35期)2018-01-25 國密SM2密碼算法的C語言實(shí)現(xiàn)中國新通信(2017年18期)2017-10-22 基于身份的聚合簽名體制研究成長·讀寫月刊(2017年4期)2017-05-16 摸清黑客套路防范木馬侵入科學(xué)24小時(2010年5期)2010-11-08 一種公開密鑰ＲＳＡ算法的實(shí)現(xiàn)安徽理工大學(xué)學(xué)報·自然科學(xué)版(2008年2期)2008-06-20
吳凌杰，孟 真，嚴(yán)俊峰
（浙江省地震局，杭州 310013）
0 引言
地震科學(xué)數(shù)據(jù)涵蓋學(xué)科多、數(shù)據(jù)體量大、時間跨度長、動態(tài)性強(qiáng)和數(shù)據(jù)結(jié)構(gòu)異構(gòu)等特點(diǎn)，導(dǎo)致現(xiàn)存系統(tǒng)在體量、功能和性能方面難以滿足數(shù)據(jù)安全共享需求[1-2]。目前，應(yīng)用程序接口（Application Programming Interface，API）做為移動設(shè)計、云計算、物聯(lián)網(wǎng)、大數(shù)據(jù)及社交網(wǎng)絡(luò)等應(yīng)用數(shù)據(jù)交互的一種核心技術(shù)[3]，為地震數(shù)據(jù)傳輸和共享提供了創(chuàng)新性和顛覆性的解決辦法。但是API的開放屬性導(dǎo)致其很容易出現(xiàn)：用戶賬號密碼被截獲、表單數(shù)據(jù)被篡改和業(yè)務(wù)數(shù)據(jù)泄露等問題，極大地威脅到使用API 傳輸?shù)卣饠?shù)據(jù)的安全性[4-6]。因此，如何使用API安全傳輸?shù)卣饠?shù)據(jù)是當(dāng)下亟需研究的一項(xiàng)課題。
目前保障API調(diào)用時數(shù)據(jù)安全的常用方案有通信使用HTTPS 協(xié)議、請求簽名、身份確認(rèn)機(jī)制和對請求響應(yīng)加解密等。HTTPS 協(xié)議[7-8]的主要作用是確認(rèn)雙方的身份和建立安全通道，保障數(shù)據(jù)的安全傳輸。但是HTTPS 不能防中間人攻擊，使用成本高，占用服務(wù)器資源多而且響應(yīng)速度慢。對于傳輸大體量數(shù)據(jù)和震情發(fā)生后的緊急情況，HTTPS并不是最優(yōu)選擇。姜建武等[9]使用雙重簽名驗(yàn)證、請求體加密等方式來加固用戶數(shù)據(jù)傳輸安全性。請求簽名在一定程度上可以保證數(shù)據(jù)傳輸安全性，但是在數(shù)據(jù)傳輸前需要提前約定密鑰。由于地震災(zāi)害的突發(fā)性和不可預(yù)測性，應(yīng)急情況下幾乎沒有條件在數(shù)據(jù)傳輸前就約定好密鑰或者輸入密鑰。殷佳庭等[10]使用請求和響應(yīng)均加解密的辦法，請求前數(shù)據(jù)先使用AES 算法加密，接收數(shù)據(jù)后再用AES 密鑰解密，由于AES 密鑰的唯一性，密鑰需要由服務(wù)端跟客戶端事先約定，同樣在地震應(yīng)急場景中一定的局限性。
綜上所述，針對地震數(shù)據(jù)體量大、對響應(yīng)速度要求高以及無法事先交換密鑰的應(yīng)急需求，本文基于RSA和AES兩種加密算法結(jié)合API運(yùn)行機(jī)制提出了一種混合加密API 算法，并將混合加密API 算法與不加密API 進(jìn)行對比，探索兩者在數(shù)據(jù)加密、API 性能和資源消耗等方面的差異并對差異產(chǎn)生的原因進(jìn)行分析解釋。
1 加密算法介紹
當(dāng)前密碼學(xué)體系中的加密算法一般分為對稱加密算法和非對稱加密算法兩種[11]。對稱加密算法就是使用相同的密鑰對數(shù)據(jù)進(jìn)行加解密。非對稱加密算法是指加解密使用不同的密鑰，通常此類算法有兩個密鑰，為公鑰和私鑰。發(fā)送方使用接收方的公鑰對明文進(jìn)行加密，接收方使用自己的私鑰進(jìn)行解密獲得明文信息。公鑰是可以對外界開放的，私鑰只能由持有人知道。
1.1 AES算法
AES 算法是當(dāng)前使用最多的分組對稱加密算法，分組指在加密和解密時把明文分成長度相等的幾組。在AES 的標(biāo)準(zhǔn)規(guī)范中，分組長度固定為128位。密鑰的長度可以使用128 位、192 位或256 位，不同的密鑰長度對應(yīng)的加密輪數(shù)也不同[12]。差異如表1所示。本文使用128位密鑰加密。
表1 AES密鑰長度和加密輪數(shù)Table 1 Key length and encryption round of AES
AES加密過程涉及到四個環(huán)節(jié)，分別為輪密鑰加、字節(jié)代換、行位移和列混淆。輪密鑰加是將128 位的密鑰同狀態(tài)矩陣中的數(shù)據(jù)進(jìn)行逐位異或操作。字節(jié)代換采用的S 盒是16×16 字節(jié)的二維表，所有元素在整個加密過程中保持定值。行位移是做一個簡單的循環(huán)移位操作。列混淆是將移位后的狀態(tài)矩陣與固定矩陣相乘。
1.2 RSA算法
RSA加密算法是當(dāng)前較為流行的一種公鑰密碼算法。算法的核心是運(yùn)用一種產(chǎn)生復(fù)雜的、偽隨機(jī)數(shù)據(jù)序列的模運(yùn)算[13]。RSA算法是建立在“大數(shù)分解和素數(shù)檢測”的理論基礎(chǔ)上，兩個大素數(shù)相乘在計算機(jī)上很容易實(shí)現(xiàn)，但是將該乘積分解為兩個大素數(shù)因子的計算量卻非常大。RSA算法需要?dú)W拉函數(shù)、歐拉定理和模反元素等基礎(chǔ)數(shù)學(xué)知識。算法生成密鑰的過程主要分為三步：①隨意生成兩個大素數(shù)p，q（p≠q），令n=p×q；②根據(jù)歐拉函數(shù)性質(zhì)可得r=φ(n)= φ( p)φ(q)=( p - 1)(q - 1)；③隨機(jī)選擇一個小于r 的整數(shù)e，且e 與r 互為素數(shù)。根據(jù)模反元素兩個正整數(shù)e 與r 互素，那么一定可以找到整數(shù)d，使得ed-1 被r 除，可求得e 關(guān)于r 的模反元素d。可得公鑰為（n，e），（n，d）是私鑰。最后銷毀p，q。
得到公鑰后，需要對明文信息m 進(jìn)行加密，將公鑰和明文信息帶入式子m∧e=c（mod n），計算得到的c即為密文。解密時將密鑰跟密文代入式子c∧d=m（mod n），即可得到明文m。
1.3 混合加密API算法
AES 算法將數(shù)據(jù)和密鑰按字節(jié)來處理，加解密運(yùn)算速度快，適用于大批量數(shù)據(jù)的處理。但由于很難解決密鑰分發(fā)的安全性和數(shù)字簽名等問題，用于API 加密傳輸時，數(shù)據(jù)的安全性較弱[14]。而RSA 算法使用公鑰加密私鑰解密，公鑰可以向外界公布，只要私鑰不泄露，很大程度能保障數(shù)據(jù)的安全性。但是RSA 算法的短板在于加解密都是進(jìn)行大數(shù)計算，處理大體量數(shù)據(jù)會增加運(yùn)算時間和設(shè)備性能消耗，用于API加密傳輸會嚴(yán)重影響數(shù)據(jù)傳輸效率[15]。為了解決AES 算法密鑰的短板，同時彌補(bǔ)RSA 算法處理速度慢的缺點(diǎn)。本文利用AES 算法運(yùn)算速度快的特性來處理需要傳輸?shù)臄?shù)據(jù)，使用RSA 算法密鑰配置特性高的特點(diǎn)配置AES密鑰，同時結(jié)合通信網(wǎng)絡(luò)的運(yùn)行機(jī)制[16]，提出了一種混合加密API算法。
算法具體流程為：當(dāng)客戶端啟動時，發(fā)送請求到服務(wù)端，服務(wù)端用RSA 算法生成公鑰publickeys和私鑰privatekeys，并將publickeys返回給客戶端?？蛻舳四玫椒?wù)端返回的公鑰后，用RSA 算法生成公鑰publickeyb和私鑰privatekeyb，并把publickeyb交給服務(wù)端，此時前后端通信建立。當(dāng)客戶端需要給服務(wù)端發(fā)送數(shù)據(jù)時，客戶端先生成128 位密鑰key，然后把需要發(fā)送的數(shù)據(jù)和key 用AES 算法加密，key 再用publickeyb加密成aeskey后和密文一并傳輸給服務(wù)端，服務(wù)端給客戶端發(fā)送數(shù)據(jù)亦是如此。在服務(wù)端與客戶端建立通訊后，前后端生成的publickey 和privatekey 不再改變，key 則會在每次傳輸數(shù)據(jù)前重新生成。服務(wù)端與客戶端通信建立流程圖如下圖1所示，數(shù)據(jù)加密傳輸流程示意圖如圖2所示。
圖1 服務(wù)端與客戶端通信示意圖Fig.1 Schematic diagram of communication between server and client
2 數(shù)據(jù)來源
地震監(jiān)測是地震學(xué)科的重要基礎(chǔ)與核心業(yè)務(wù)。由于地球內(nèi)部的不可入性，目前只能在地表建設(shè)大量的觀測臺站來監(jiān)測地震情況，臺站產(chǎn)生的數(shù)據(jù)再通過龐大的網(wǎng)絡(luò)系統(tǒng)進(jìn)行匯聚[17]。因此地震科學(xué)數(shù)據(jù)主要來源就是臺站的基礎(chǔ)數(shù)據(jù)和觀測數(shù)據(jù)。本文選用國家地震烈度速報與預(yù)警工程中臺站監(jiān)控系統(tǒng)的臺站基礎(chǔ)數(shù)據(jù)表來驗(yàn)證算法的加密效果。臺站基礎(chǔ)數(shù)據(jù)表結(jié)構(gòu)見表2，其中臺站的位置和通信數(shù)據(jù)等都為敏感數(shù)據(jù)。同時選用浙江省地球物理臺網(wǎng)海寧臺垂直擺傾斜觀測系統(tǒng)東西分量24 h的記錄量作為測試API性能數(shù)據(jù)，該系統(tǒng)每秒鐘記錄一次數(shù)據(jù)，一天的數(shù)據(jù)量會打包在一起。
圖2 數(shù)據(jù)加密傳輸流程圖Fig.2 Flow chart of data encryption transmission process
3 實(shí)驗(yàn)結(jié)果與分析
3.1 加密性驗(yàn)證
本文使用JAVA 語言和Springboot 框架實(shí)現(xiàn)混合加密API 和不加密API 的功能。為了驗(yàn)證混合加密API 能否在實(shí)際業(yè)務(wù)中有效的加密和傳輸數(shù)據(jù)。本文設(shè)置了如下交互方式，當(dāng)服務(wù)端與客戶端建立通信后，客戶端以HTTP 協(xié)議發(fā)起POST 請求且請求攜帶參數(shù)為data="stationimf ormation"時，服務(wù)端以JSON 格式的臺站敏感數(shù)據(jù)響應(yīng)。實(shí)驗(yàn)過程中通過抓包軟件抓取加密和不加密API請求和響應(yīng)的數(shù)據(jù)。未加密API 抓包數(shù)據(jù)如圖3 所示，加密API抓包數(shù)據(jù)如圖4所示。
表2 臺站基礎(chǔ)數(shù)據(jù)表Table 2 Basic data of station
圖3 未加密API數(shù)據(jù)抓包圖Fig.3 Unencrypted API data packet capture diagram
圖4 加密API數(shù)據(jù)抓包圖Fig.4 Encrypted API data packet capture diagram
圖中請求體的參數(shù)Name 和Value 分別表示客戶端POST請求攜帶的參數(shù)名稱和值，JSON為客戶端返回的數(shù)據(jù)。從圖3 可以看出，未加密API 客戶端請求參數(shù)data 和服務(wù)端返回的JSON 數(shù)據(jù)都被抓到，臺站敏感數(shù)據(jù)一覽無余。而圖4中aesKey為使用后端公鑰加密的AES密鑰，data為請求數(shù)據(jù)，均為密文。返回的JSON 信息也為密文。在無法獲得密鑰的情況下，想要破解密文的難度非常大，很好的保護(hù)臺站敏感數(shù)據(jù)的安全性，為地震數(shù)據(jù)安全傳輸提供了可靠的保證。
3.2 接口性能測試
為了測試混合加密API在實(shí)際業(yè)務(wù)中的接口性能表現(xiàn)，本文使用由Apache 公司基于Java 開發(fā)的API 性能檢測工具Jmeter 來做測試。該軟件可以模擬用戶對API 發(fā)起請求和接受響應(yīng)，且可以編寫Java腳本對數(shù)據(jù)進(jìn)行加解密操作。由于Jmeter在做批量測試時，無法先從服務(wù)端獲取公鑰，因此在編寫Jmeter 測試腳本時，需先將后端公鑰寫進(jìn)腳本，保證首次發(fā)起請求時客戶端與服務(wù)端已建立通信。
同樣以未加密API作為對照組進(jìn)行測試，測試使用Jmeter 軟件模擬用戶以HTTP 協(xié)議對API 發(fā)起1 進(jìn)程500 次的POST 請求。發(fā)起請求時，未加密API直接將臺站觀測數(shù)據(jù)作為請求參數(shù)發(fā)送，服務(wù)端接收后原樣返回測試數(shù)據(jù)，Jmeter接收數(shù)據(jù)后完成一次請求與響應(yīng)。加密API則在發(fā)起請求前先將臺站觀測數(shù)據(jù)進(jìn)行加密，以密文作為請求參數(shù)，服務(wù)端在獲取密文進(jìn)行解密后，再將測試數(shù)據(jù)進(jìn)行加密返回給Jmeter，等到Jmeter 解密獲得明文，完成一次請求與響應(yīng)過程。為減小網(wǎng)絡(luò)因素給測試結(jié)果帶來誤差，客戶端與服務(wù)端運(yùn)行在同一子網(wǎng)內(nèi)。服務(wù)器為32 GB 內(nèi)存，2.4 GHz CPU 的深信服云服務(wù)器。未加密與混合加密API請求響應(yīng)時間圖如5 和圖6 所示。請求響應(yīng)時間是指從客戶端發(fā)送一個請求，到客戶端接收到服務(wù)器返回響應(yīng)結(jié)果時長。
圖5 未加密API請求響應(yīng)時間圖Fig.5 Request response time graph of unencrypted API
圖6 加密API請求響應(yīng)時間圖Fig.6 Request response time graph of encrypted API
從圖中可以看到，首次發(fā)起請求的響應(yīng)時間都是最長的，這是因?yàn)镠TTP 是建立在TCP 之上的，TCP 握手會占用一定時間。從第二次開始，響應(yīng)時間基本趨于穩(wěn)定。但是混合加密API 與未加密API響應(yīng)時間存在差值。于是本文統(tǒng)計了所有請求的響應(yīng)時間，如表3所示。
從表中可以看出，混合加密API運(yùn)行穩(wěn)定無失敗。加密API 平均響應(yīng)時間比未加密API 多6.97ms，在忽略網(wǎng)絡(luò)等其他影響因素的情況下，這個時間即為服務(wù)器處理加解密算法的平均時長。統(tǒng)計發(fā)現(xiàn)，90%的響應(yīng)時間差均在8ms以內(nèi)，時間差幾乎可以忽略不計。因此，混合加密API對地震數(shù)據(jù)傳輸速度產(chǎn)生的影響可以忽略不計。
由于地震系統(tǒng)有很多觀測系統(tǒng)，在匯聚傳輸不加密數(shù)據(jù)時會對服務(wù)器的性能有較高的要求，因此接口的性能消耗也是一項(xiàng)非常重要的指標(biāo)。于是本文還記錄了響應(yīng)過程中服務(wù)器的CPU 和內(nèi)存使用率分別，如圖7和圖8所示。
表3 接口響應(yīng)時間表Table 3 Response timetable of interface
圖7 未加密API運(yùn)行性能圖Fig.7 Running performance graph of unencrypted API
對比內(nèi)存使用量，兩種接口對內(nèi)存的消耗幾乎相等，因此混合加密API 對內(nèi)存的影響和消耗不大。對于CPU性能來說，未加密API運(yùn)行時CPU平均使用率約為0.71%，混合加密API 為1.92%，相差1.21%，CPU資源占用量不多。
圖8 加密API運(yùn)行性能圖Fig.8 Running performance graph of encrypted API
3.3 局限性分析
網(wǎng)絡(luò)攻防就像矛與盾，沒有絕對鋒利的矛也沒有絕對堅硬的盾。本文介紹的混合加密API算法在一定程度上保障了地震數(shù)據(jù)傳輸?shù)陌踩院头€(wěn)定性，但并不能完全阻止中間人的攻擊，只能增加中間人的攻擊成本。此外，數(shù)據(jù)安全傳輸?shù)姆桨赣泻芏喾N，安全性的提高，必然也會帶來成本、資源和時間消耗的增加。
4 結(jié)論
本文以AES 和RSA 加密算法為基礎(chǔ)，結(jié)合API運(yùn)行機(jī)制，將兩種算法優(yōu)勢互補(bǔ)取長補(bǔ)短，構(gòu)建了一種混合加密API 算法。通過與不加密API 進(jìn)行比較，分析了兩種不同地震系統(tǒng)數(shù)據(jù)，研究了混合加密API在地震數(shù)據(jù)傳輸?shù)陌踩?、穩(wěn)定性、快速性、適應(yīng)性和資源消耗方面的特點(diǎn)。研究結(jié)論主要有以下幾點(diǎn)：
（1）混合加密API 算法能有效地對API 傳輸?shù)臄?shù)據(jù)進(jìn)行加密，在一定程度上保障了地震數(shù)據(jù)的安全性。
（2）在實(shí)際業(yè)務(wù)中，無需提前交換密鑰，混合加密API算法就能高效穩(wěn)定地運(yùn)行，保障了應(yīng)急情況下地震數(shù)據(jù)的安全傳輸。
（3）混合加密API 算法對地震數(shù)據(jù)的傳輸速度不會產(chǎn)生影響。
（4）混合加密API 算法要對數(shù)據(jù)進(jìn)行加解密計算，對計算機(jī)的CPU 資源有一定的消耗，對內(nèi)存幾乎無消耗?？傮w來說，只占用了少量的服務(wù)器資源。
猜你喜歡
科技與創(chuàng)新(2021年24期)2022-01-03
科技研究·理論版(2021年20期)2021-04-20
中小企業(yè)管理與科技·下旬刊(2021年1期)2021-03-02
知識就是力量(2018年10期)2018-10-18
消費(fèi)導(dǎo)刊(2018年8期)2018-05-25
價值工程(2018年35期)2018-01-25
中國新通信(2017年18期)2017-10-22
成長·讀寫月刊(2017年4期)2017-05-16
科學(xué)24小時(2010年5期)2010-11-08
安徽理工大學(xué)學(xué)報·自然科學(xué)版(2008年2期)2008-06-20
