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字节的二维表，所有元素在整个加密过程中保持定值。行位移是做一个简单的循环移位操作。列混淆是将移位后的状态矩阵与固定矩阵相乘。

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（ m o d n），即可得到明文m。

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

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

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

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

本文使用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信息也为密文。在无法获得密钥的情况下，想要破解密文的难度非常大，很好的保护台站敏感数据的安全性，为地震数据安全传输提供了可靠的保证。

为了测试混合加密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所示。

表3 接口响应时间表Table 3 Response timetable of interface

图7 未加密API运行性能图Fig.7 Running performance graph of unencrypted API

图8 加密API运行性能图Fig.8 Running performance graph of encrypted API

对比内存使用量，两种接口对内存的消耗几乎相等，因此混合加密API对内存的影响和消耗不大。对于CPU性能来说，未加密API运行时CPU平均使用率约为0.71%，混合加密API为1.92%，相差1.21%，CPU资源占用量不多。

网络攻防就像矛与盾，没有绝对锋利的矛也没有绝对坚硬的盾。本文介绍的混合加密API算法在一定程度上保障了地震数据传输的安全性和稳定性，但并不能完全阻止中间人的攻击，只能增加中间人的攻击成本。此外，数据安全传输的方案有很多种，安全性的提高，必然也会带来成本、资源和时间消耗的增加。