基于混合加密API算法对地震数据安全传输的研究

2022-08-03吴凌杰严俊峰

华南地震 2022年2期

吴凌杰，孟真，严俊峰

（浙江省地震局，杭州 310013）

0 引言

地震科学数据涵盖学科多、数据体量大、时间跨度长、动态性强和数据结构异构等特点，导致现存系统在体量、功能和性能方面难以满足数据安全共享需求[1-2]。目前，应用程序接口（Application Programming Interface，API）做为移动设计、云计算、物联网、大数据及社交网络等应用数据交互的一种核心技术[3]，为地震数据传输和共享提供了创新性和颠覆性的解决办法。但是API的开放属性导致其很容易出现：用户账号密码被截获、表单数据被篡改和业务数据泄露等问题，极大地威胁到使用API 传输地震数据的安全性[4-6]。因此，如何使用API安全传输地震数据是当下亟需研究的一项课题。

目前保障API调用时数据安全的常用方案有通信使用HTTPS 协议、请求签名、身份确认机制和对请求响应加解密等。HTTPS 协议[7-8]的主要作用是确认双方的身份和建立安全通道，保障数据的安全传输。但是HTTPS 不能防中间人攻击，使用成本高，占用服务器资源多而且响应速度慢。对于传输大体量数据和震情发生后的紧急情况，HTTPS并不是最优选择。姜建武等[9]使用双重签名验证、请求体加密等方式来加固用户数据传输安全性。请求签名在一定程度上可以保证数据传输安全性，但是在数据传输前需要提前约定密钥。由于地震灾害的突发性和不可预测性，应急情况下几乎没有条件在数据传输前就约定好密钥或者输入密钥。殷佳庭等[10]使用请求和响应均加解密的办法，请求前数据先使用AES 算法加密，接收数据后再用AES 密钥解密，由于AES 密钥的唯一性，密钥需要由服务端跟客户端事先约定，同样在地震应急场景中一定的局限性。

综上所述，针对地震数据体量大、对响应速度要求高以及无法事先交换密钥的应急需求，本文基于RSA和AES两种加密算法结合API运行机制提出了一种混合加密API 算法，并将混合加密API 算法与不加密API 进行对比，探索两者在数据加密、API 性能和资源消耗等方面的差异并对差异产生的原因进行分析解释。

1 加密算法介绍

当前密码学体系中的加密算法一般分为对称加密算法和非对称加密算法两种[11]。对称加密算法就是使用相同的密钥对数据进行加解密。非对称加密算法是指加解密使用不同的密钥，通常此类算法有两个密钥，为公钥和私钥。发送方使用接收方的公钥对明文进行加密，接收方使用自己的私钥进行解密获得明文信息。公钥是可以对外界开放的，私钥只能由持有人知道。

1.1 AES算法

AES 算法是当前使用最多的分组对称加密算法，分组指在加密和解密时把明文分成长度相等的几组。在AES 的标准规范中，分组长度固定为128位。密钥的长度可以使用128 位、192 位或256 位，不同的密钥长度对应的加密轮数也不同[12]。差异如表1所示。本文使用128位密钥加密。

表1 AES密钥长度和加密轮数Table 1 Key length and encryption round of AES

AES加密过程涉及到四个环节，分别为轮密钥加、字节代换、行位移和列混淆。轮密钥加是将128 位的密钥同状态矩阵中的数据进行逐位异或操作。字节代换采用的S 盒是16×16 字节的二维表，所有元素在整个加密过程中保持定值。行位移是做一个简单的循环移位操作。列混淆是将移位后的状态矩阵与固定矩阵相乘。

1.2 RSA算法

RSA加密算法是当前较为流行的一种公钥密码算法。算法的核心是运用一种产生复杂的、伪随机数据序列的模运算[13]。RSA算法是建立在“大数分解和素数检测”的理论基础上，两个大素数相乘在计算机上很容易实现，但是将该乘积分解为两个大素数因子的计算量却非常大。RSA算法需要欧拉函数、欧拉定理和模反元素等基础数学知识。算法生成密钥的过程主要分为三步：①随意生成两个大素数p，q（p≠q），令n=p×q；②根据欧拉函数性质可得r=φ(n)= φ( p)φ(q)=( p - 1)(q - 1)；③随机选择一个小于r 的整数e，且e 与r 互为素数。根据模反元素两个正整数e 与r 互素，那么一定可以找到整数d，使得ed-1 被r 除，可求得e 关于r 的模反元素d。可得公钥为（n，e），（n，d）是私钥。最后销毁p，q。

得到公钥后，需要对明文信息m 进行加密，将公钥和明文信息带入式子m∧e=c（mod n），计算得到的c即为密文。解密时将密钥跟密文代入式子c∧d=m（mod n），即可得到明文m。

1.3 混合加密API算法

AES 算法将数据和密钥按字节来处理，加解密运算速度快，适用于大批量数据的处理。但由于很难解决密钥分发的安全性和数字签名等问题，用于API 加密传输时，数据的安全性较弱[14]。而RSA 算法使用公钥加密私钥解密，公钥可以向外界公布，只要私钥不泄露，很大程度能保障数据的安全性。但是RSA 算法的短板在于加解密都是进行大数计算，处理大体量数据会增加运算时间和设备性能消耗，用于API加密传输会严重影响数据传输效率[15]。为了解决AES 算法密钥的短板，同时弥补RSA 算法处理速度慢的缺点。本文利用AES 算法运算速度快的特性来处理需要传输的数据，使用RSA 算法密钥配置特性高的特点配置AES密钥，同时结合通信网络的运行机制[16]，提出了一种混合加密API算法。

算法具体流程为：当客户端启动时，发送请求到服务端，服务端用RSA 算法生成公钥publickeys和私钥privatekeys，并将publickeys返回给客户端。客户端拿到服务端返回的公钥后，用RSA 算法生成公钥publickeyb和私钥privatekeyb，并把publickeyb交给服务端，此时前后端通信建立。当客户端需要给服务端发送数据时，客户端先生成128 位密钥key，然后把需要发送的数据和key 用AES 算法加密，key 再用publickeyb加密成aeskey后和密文一并传输给服务端，服务端给客户端发送数据亦是如此。在服务端与客户端建立通讯后，前后端生成的publickey 和privatekey 不再改变，key 则会在每次传输数据前重新生成。服务端与客户端通信建立流程图如下图1所示，数据加密传输流程示意图如图2所示。

图1 服务端与客户端通信示意图Fig.1 Schematic diagram of communication between server and client

2 数据来源

地震监测是地震学科的重要基础与核心业务。由于地球内部的不可入性，目前只能在地表建设大量的观测台站来监测地震情况，台站产生的数据再通过庞大的网络系统进行汇聚[17]。因此地震科学数据主要来源就是台站的基础数据和观测数据。本文选用国家地震烈度速报与预警工程中台站监控系统的台站基础数据表来验证算法的加密效果。台站基础数据表结构见表2，其中台站的位置和通信数据等都为敏感数据。同时选用浙江省地球物理台网海宁台垂直摆倾斜观测系统东西分量24 h的记录量作为测试API性能数据，该系统每秒钟记录一次数据，一天的数据量会打包在一起。

图2 数据加密传输流程图Fig.2 Flow chart of data encryption transmission process

3 实验结果与分析

3.1 加密性验证

本文使用JAVA 语言和Springboot 框架实现混合加密API 和不加密API 的功能。为了验证混合加密API 能否在实际业务中有效的加密和传输数据。本文设置了如下交互方式，当服务端与客户端建立通信后，客户端以HTTP 协议发起POST 请求且请求携带参数为data="stationimf ormation"时，服务端以JSON 格式的台站敏感数据响应。实验过程中通过抓包软件抓取加密和不加密API请求和响应的数据。未加密API 抓包数据如图3 所示，加密API抓包数据如图4所示。

表2 台站基础数据表Table 2 Basic data of station

图3 未加密API数据抓包图Fig.3 Unencrypted API data packet capture diagram

图4 加密API数据抓包图Fig.4 Encrypted API data packet capture diagram

图中请求体的参数Name 和Value 分别表示客户端POST请求携带的参数名称和值，JSON为客户端返回的数据。从图3 可以看出，未加密API 客户端请求参数data 和服务端返回的JSON 数据都被抓到，台站敏感数据一览无余。而图4中aesKey为使用后端公钥加密的AES密钥，data为请求数据，均为密文。返回的JSON 信息也为密文。在无法获得密钥的情况下，想要破解密文的难度非常大，很好的保护台站敏感数据的安全性，为地震数据安全传输提供了可靠的保证。

3.2 接口性能测试

为了测试混合加密API在实际业务中的接口性能表现，本文使用由Apache 公司基于Java 开发的API 性能检测工具Jmeter 来做测试。该软件可以模拟用户对API 发起请求和接受响应，且可以编写Java脚本对数据进行加解密操作。由于Jmeter在做批量测试时，无法先从服务端获取公钥，因此在编写Jmeter 测试脚本时，需先将后端公钥写进脚本，保证首次发起请求时客户端与服务端已建立通信。

同样以未加密API作为对照组进行测试，测试使用Jmeter 软件模拟用户以HTTP 协议对API 发起1 进程500 次的POST 请求。发起请求时，未加密API直接将台站观测数据作为请求参数发送，服务端接收后原样返回测试数据，Jmeter接收数据后完成一次请求与响应。加密API则在发起请求前先将台站观测数据进行加密，以密文作为请求参数，服务端在获取密文进行解密后，再将测试数据进行加密返回给Jmeter，等到Jmeter 解密获得明文，完成一次请求与响应过程。为减小网络因素给测试结果带来误差，客户端与服务端运行在同一子网内。服务器为32 GB 内存，2.4 GHz CPU 的深信服云服务器。未加密与混合加密API请求响应时间图如5 和图6 所示。请求响应时间是指从客户端发送一个请求，到客户端接收到服务器返回响应结果时长。

图5 未加密API请求响应时间图Fig.5 Request response time graph of unencrypted API

图6 加密API请求响应时间图Fig.6 Request response time graph of encrypted API

从图中可以看到，首次发起请求的响应时间都是最长的，这是因为HTTP 是建立在TCP 之上的，TCP 握手会占用一定时间。从第二次开始，响应时间基本趋于稳定。但是混合加密API 与未加密API响应时间存在差值。于是本文统计了所有请求的响应时间，如表3所示。

从表中可以看出，混合加密API运行稳定无失败。加密API 平均响应时间比未加密API 多6.97ms，在忽略网络等其他影响因素的情况下，这个时间即为服务器处理加解密算法的平均时长。统计发现，90%的响应时间差均在8ms以内，时间差几乎可以忽略不计。因此，混合加密API对地震数据传输速度产生的影响可以忽略不计。

由于地震系统有很多观测系统，在汇聚传输不加密数据时会对服务器的性能有较高的要求，因此接口的性能消耗也是一项非常重要的指标。于是本文还记录了响应过程中服务器的CPU 和内存使用率分别，如图7和图8所示。