CN114915495B - 一种支持多种算法切换的报文加解密方法 - Google Patents

Abstract

本发明公开了一种支持多种算法切换的报文加解密方法，包括以下步骤：在应用程序服务端与应用程序客户端创建请求拦截器和响应拦截器；进行加解密配置；应用程序服务端监听配置中心的配置变化，应用程序服务端和应用程序客户端根据配置中心的配置变化进行配置更新；应用程序服务端和应用程序客户端拦截请求和响应；判断拦截到的请求或响应是否执行加解密；对需要加解密的请求和响应执行加解密处理。本发明通过对数据传输的报文信息进行双向加密，从而确保信息系统中数据交互的安全性，并且支持根据配置自由切换加密算法，快速应对不同安全需求、提升系统的灵活性。

Description

一种支持多种算法切换的报文加解密方法

技术领域

本发明涉及信息系统中数据传输的报文加解密领域，具体涉及一种支持多种算法切换的报文加解密方法。

背景技术

随着互联网技术的发展与迭代，前后端分离成为目前一种主流的开发模式，它使系统的分工更加明确，将应用程序分为了两个端：后端和前端。后端即应用程序服务端，负责处理和存储数据。前端即应用程序客户端，负责显示数据。

然而，技术变革激发生产力的同时也大大增加了系统的不安全性，应用程序服务端与应用程序客户端的API（Application Programming Interface,应用程序编程接口）进行数据交互的报文仅仅通过明文进行传输，易发生敏感信息泄露、被劫持的安全漏洞。

当前市面上针对报文加密的需求，技术方案大多通过单一的算法进行实现。算法有很多种，例如：MD5（MD5 Message-Digest Algorithm，MD5是由美国密码学家罗纳德·李维斯特[Ronald Linn Rivest]设计，于1992年发布的信息摘要算法）、SHA-1（Secure HashAlgorithm 1、安全散列算法1）等，但这些算法不适用于报文加密这一场景，因报文加密场景的算法需满足：安全等级高、加密后的报文体积小、解密速度快等特性。

适用于报文加密的算法有：AES（Advanced Encryption Standard，高级加密标准算法）、DES（Data Encryption Standard，数据加密标准算法）、SM2（国密的一种算法，是国家密码管理局于2010年12月17日发布的椭圆曲线公钥密码算法）、RSA（一种公开密钥算法，以它的三个发明者 Ron Rivest, Adi Shamir, Leonard Adleman 的名字首字母命名）、SM4（分组密码算法，也是国密的一种算法）等。

然而，现有的API报文加解密技术普遍存在以下不足：

1、当需求发生变化需要切换不同的算法进行加密时，只能通过大量修改系统源码，重启系统服务来实现，无法支持加密算法根据需求动态变化，为系统的开发与运维带来极大的困扰与不确定性。

2、现有API接口报文传输进行加解密时，每新增一个API接口都需要配置它是否需要加解密，一个系统可能拥有上万个API接口，导致配置的工作量极其繁重。

3、当前应用程序对API接口的报文传输进行加密后，由于没有开关，故无法关闭加密，当程序出现BUG时，加密后的报文不可阅读、无法理解，导致开发、运维人员不能快速定位问题，修复程序BUG。

发明内容

针对现有技术上述缺陷，本发明提出一种支持多种算法切换的报文加解密方法，它通过对应用程序服务端与应用程序客户端传输的报文进行双向加密，保证应用程序服务端与应用程序客户端数据交互的安全性,同时，当系统安全需求发生变化时，需要切换不同的算法进行加密，本发明的方法能够支持多种算法动态切换，并且不需要进行应用程序服务端重新部署，快速满足不同需求下的系统安全需求。

为此，本发明提供一种支持多种算法切换的报文加解密方法，包括如下步骤：

S1、在服务端与客户端创建请求拦截器和响应拦截器；

S2、在配置中心的Server端、应用程序服务端与客户端进行加解密配置；

S3、服务端监听配置中心的配置变化，服务端和客户端根据配置中心的配置变化进行配置更新；

S4、服务端和客户端拦截请求或响应；

S5、判断拦截到的请求或响应是否执行加解密；

S6、对加解密的请求或响应执行加解密处理。

优选的，所述在配置中心的Server端、应用程序服务端与客户端进行加解密配置包括：

1）在配置中心的Server端中，创建一个公共的加解密配置文件，用于存储加解密配置项；

2）在应用程序服务端与客户端，分别创建一个配置文件，其中：服务端配置文件存储配置中心Server端的地址和加解密配置文件；客户端配置文件中存储加解密配置项。

优选的，所述加解密配置项包括：为是否开启加解密进行配置的是否开启加解密配置项、为每个算法配置算法密钥的算法密钥配置项、为对不能进行加解密的API接口的URL进行忽略加解密配置的URL忽略加解密配置项。

优选的，在算法密钥配置项进行配置时，对算法密钥再进行一次Base64加密。

优选的，所述URL忽略加解密配置项包括：当前序号、资源路径URL、请求方法类型、忽略请求加解密还是响应加解密。

优选的，所述服务端监听配置中心的配置变化，服务端和客户端根据配置中心的配置变化进行配置更新包括如下步骤：

1）在应用程序服务端嵌入一个配置中心的Client组件包，应用程序服务端即为配置中心的Client端；

2）应用程序服务端启动运行，服务端通过本身存储的配置中心Server端地址，主动与配置中心的Server端连接，获取配置中心的配置信息，将这些配置加载到本地，并与配置中心Server端保持长链接；

3）应用程序客户端配置更新，和配置中心Server端的配置保持一致。

优选的，所述对拦截到的请求或响应是否执行加解密进行判断包括：

1）在对应的请求或响应拦截器中，获取配置中是否开启加解密配置的配置项，判断该配置项的值是否为True，如果是，则执行后续的判断流程；如果不是，则不对拦截到的请求或响应进行加解密操作，结束；

2）判断URL忽略加解密配置是否满足：根据取到的当前请求或响应的URL的路径，逐个取出配置中URL忽略加解密的配置数据进行比对，比对是否存在对应URL路径；如果存在对应URL路径，将该URL路径的请求方法类型、是请求还是响应，与该URL的路径对应配置中的请求方法类型和忽略加解密还是响应加解密的配置数据进行比对。

优选的，所述对加解密的请求或响应执行加解密处理包括如下步骤：

1）在拦截器中获取不同算法对应的算法密钥；

2）在拦截器中调用不同算法实现的工具类，通过算法密钥对拦截器中拦截到的请求或响应的报文做加解密。

本发明的有益效果如下：

本发明实施例的报文加解密方法是一种全新的支持多种算法切换的报文加解密方法，采用本发明技术方案加密后的报文为乱码传输，具备不可阅读、无法理解的特性，且加密后的报文无算法密钥无法解密，可解决报文传输中敏感信息泄露、被劫持的安全漏洞，大大增加了系统的安全性。

本发明实施例默认所有报文传输的API接口都需要进行加解密，对于不能进行加解密的API接口可配置为忽略，无需每新增一个API接口都需要配置它是否需要进行加解密，只做例外的忽略，可大大减少配置的工作量。

本发明实施例支持应用程序服务端加解密配置更改后实时生效，例如：系统将原本使用的AES加密算法变更为使用国密算法SM4算法进行加密，修改配置后，无需重新部署应用程序服务端，即时生效，可大大降低应用程序服务端运维的复杂度。

本实施例配置了是否开启加解密的开关，可分别控制应用程序服务端和应用程序客户端是否开启加解密，该配置可以灵活控制不同安全标准下加解密的需求，在安全标准不高的环境下关闭应用程序加解密，当应用程序出现BUG时，开发、运维人员能够对BUG进行快速修复。

综上：采用本发明方法，能大幅度提高整个系统安全方面的灵活性、降低工作量，同时大大降低系统的运维难度。

附图说明

图1为本发明实施例支持多种算法切换的报文加解密方法流程示意图；

图2为本发明实施例配置文件存放位置示意图；

图3为本发明实施例系统加密配置示意图；

图4为本发明实施例配置忽略URL的示意图；

图5为本发明实施例忽略请求还是响应的规则示意图；

图6为本发明实施例应用程序服务端实时刷新配置的流程图；

图7为本发明实施举例拦截到的请求或响应的URL数据与加解密配置的示意图；

图8为本发明实施例判断拦截的请求或响应是否执行加解密的流程图。

具体实施方式

下面结合本发明的附图和具体实施例，对本发明作进一步的详细说明。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。除非另作定义，此处使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。

如图1所示为一种支持多种算法切换的报文加解密方法实施例流程示意图，包括如下操作步骤：

S1：在应用程序服务端与应用程序客户端创建请求拦截器和响应拦截器。

应用程序服务端与应用程序客户端要完成对原始报文的加解密，需要使用拦截器（Interceptor）对应用程序服务端和应用程序客户端发出的报文请求和响应进行拦截。本实施例中，在应用程序服务端与应用程序客户端各自都需要创建一个请求拦截器和响应拦截器。拦截器用于对请求和响应进行拦截，并经过判断该请求和响应是否要执行加解密后执行加解密操作。

一般应用程序都会采用特定的框架开发服务端与应用程序客户端程序，比如：应用程序客户端采用Vue框架（是一套用于构建用户界面的渐进式JavaScript框架）、应用程序服务端采用Spring框架（是一个开放源代码的J2EE应用程序框架，由Rod Johnson发起，是针对bean的生命周期进行管理的轻量级容器），每种框架都有对应的拦截器供开发者使用。

1、应用程序客户端创建拦截器

本实施例应用程序客户端基于Vue框架的Axios库（Axios是一个基于Promise的HTTP库，是Promise的实现版本，符合最新的ES规范）进行请求、响应的拦截。本实施例中，应用程序客户端的拦截请求创建一个Axios库的RequestInterceptors请求拦截器；拦截响应创建一个ResponseInterceptors响应拦截器。

创建完请求拦截器和响应拦截器后需要在Axios中进行注册，注册后的拦截器才能正常使用。

2、应用程序服务端创建拦截器

本实施例应用程序服务端基于Spring框架自带的拦截器进行请求、响应的拦截。Spring提供了两个拦截器：RequestBodyAdvice和ResponseBodyAdvice，前者负责拦截请求，后者负责拦截响应。

需要说明的是，本实施例使用上述两个拦截器时，需要先创建两个程序类。创建后的程序类继承对应的拦截器，即拥有被继承类的拦截能力。继承后的请求拦截器可以命名为ApiDecryptRequestBodyAdvice，继承后的响应拦截器可以命名为ApiEncryptResponseBodyAdvice。

创建完请求拦截器和响应拦截器后需要在Spring中进行注册，注册后的拦截器才能正常使用。

需要说明的是，若本实施例的应用程序客户端和应用程序服务端基于其他框架开发，则需要创建对应框架的请求拦截器和响应拦截器，在此不赘述。

S2：进行加解密配置

本实施例中配置文件采用的格式为YAML格式，该格式YAML是“YAML Ain't aMarkup Language”（YAML不是一种标记语言)的递归缩写，通常以.yml为后缀的文件，是一种直观的能够被电脑识别的数据序列化格式，并且容易被人类阅读，容易和脚本语言交互，可以被多种编程语言支持。

如图2所示，本实施例的加解密配置，需要配置中心、应用程序服务端、应用程序客户端配合完成。

应用程序在启动和运行的时候往往需要读取一些配置信息，这些配置通常采取两种形式进行存放：一种放在应用程序本身中，每次变更配置需要重启应用程序；一种集中式存放在配置中心，每次配置修改后由配置中心提供实时刷新能力。

常见的配置中心选型有Nacos、Apollo等。Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用的不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景；Nacos是阿里巴巴开源的服务注册中心以及配置中心，致力于给开发者提供一款便捷、简单上手的开源框架。

本实施例选用Nacos作为配置中心。本实施例的配置中心包含两个端：一个为Server端（即服务端），与应用程序分开进行部署，存放各种配置文件；一个为Client端（即客户端），嵌入在应用程序本身中，负责和Server端进行交互。

配置中心为各种编程语言开发了配套的Client组件包，比如：Java语言的Client组件包为Jar包、Golang语言的Client组件包为Go包。

配置中心存放的配置基本上伴随着应用程序的整个生命周期。常见的配置比如：数据库连接参数、启动参数、加解密配置等。

以下是本实施例加解密配置的具体步骤：

首先，本实施例中，在配置中心的Server端中，创建一个公共的加解密配置文件，文件名可命名为common-jasypt.yml，此配置文件中存储加解密的详细配置项。如图2所示，配置文件C、D、E为配置中心存放的各种配置文件，其中一个作为存放加解密信息的配置文件，文件名为common-jasypt.yml。

然后，在应用程序服务端与应用程序客户端，分别创建一个配置文件，应用程序服务端配置文件可命名为jasypt.yml，应用程序客户端配置文件可命名为jasypt.js。如图2所示，配置文件A为服务端本地配置文件即jasypt.yml；配置文件B为服务端本地配置文件即jasypt.js。详细说明如下：

应用程序服务端配置文件jasypt.yml存储配置中心Server端的地址、配置中心的加解密配置文件名两项配置。通过这两项配置读取配置中心Server端中common-jasypt.yml文件里加解密配置信息。

应用程序客户端配置文件中存储加解密的详细配置项，应用程序客户端配置文件所存储的加解密配置项内容与配置中心Server端加解密配置项一致。

图3所示为本实施例的应用程序客户端和配置中心Server端的加解密配置项，包括：是否开启加解密、算法密钥、忽略加解密的URL规则配置。详细配置说明如下：

1、是否开启加解密配置项为是否开启加解密进行配置，该配置项为一个布尔值：True、False，该配置是一个总体的全局开关，分别控制应用程序服务端和应用程序客户端是否开启加解密。默认值为False，可设为全部不开启。该配置可以灵活控制不同安全标准下加解密的需求，例如，在系统开发环境下，由于安全标准相对低，可以选择不开启加解密，方便开发人员进行程序调试，而在正式环境下，由于安全标准相对高，则可以要求开启加解密，保证报文数据传输的安全性。

2、算法密钥配置项为对应每个算法配置算法密钥。不同的算法都有各自的密钥，根据算法设计本身的不同，分为对称算法和非对称算法两种，如，AES、DES、SM4是对称算法，RSA、SM2是非对称算法。两种算法的密钥个数不同，对称算法密钥通常为一个，非对称算法密钥通常为一对。

需要说明的是，由于密钥通常为一定长度的乱码字符串，为了方便阅读，会在算法密钥配置项进行配置时，对算法密钥再进行一次Base64加密，以方便阅读，同时，经过再一次的Base64加密，可以提高密钥安全性。

3、URL忽略加解密配置项为对不能进行加解密的API接口的URL进行忽略加解密配置。

本发明实施例默认所有报文传输的API接口都需要进行加解密，对于不能进行加解密的API接口可配置为忽略，用来处理当系统遇到不能对API接口的请求或者响应进行加解密时，可以将该请求或者响应的URL配置为忽略加解密。例如：如果某个文件本身不能进行加解密，那么该文件上传的API需要进行请求忽略，该文件的下载需要进行响应忽略。

如图4所示，本实施例中，对URL忽略加解密配置包括四个配置项：当前序号、资源路径URL、请求方法类型、忽略请求加解密还是响应加解密。具体说明如下：

1）当前序号配置项为标明某一条忽略加解密配置的URL所处的位置。由于可能存在多个需要进行忽略加解密配置的URL，通常需要采用集合的数据结构进行存储，集合的数据结构可以是数组、队列等形式。每条忽略加解密配置的URL的当前序号通常由自然数0开始进行累加排列。忽略加解密配置的URL为多个时，如，用数组结构存储时，数组中的位置通常用下标位置表示，每增加一条配置，数组的下标值加1，数组的下标值即表示忽略加解密配置的URL所处的位置。

2）资源路径URL配置项为发起请求的API的URL地址。需要说明的是，本实施例中，为了能够批量地对URL进行忽略加解密配置，资源路径URL配置项支持URL通配符匹配，所述URL通配符为匹配某个URL是否满足规则的符号。

以下是以“*”号作为通配符的举例。例如，当配置为“/API/**”时，则以“/API”开头的URL都满足匹配规则。又如，“/**/file”，表示以文件结尾的URL都进行忽略加解密，减少了大批量配置的工作量。

3）请求方法类型配置项为以请求方法类型作为标准进行配置，用来匹配当前发起API接口的请求类型。

本实施例中，报文的请求方法类型一般是采用HTTP协议的方法类型，HTTP协议的方法类型通常包含GET、POST、PUT、DELETE等。因随着REST风格（Representational StateTransfer，简称REST，为一种软件架构风格）URL的API接口的流行，导致了这些API接口的URL路径可能为同一个，然而，只比对API接口的路径无法精确地区分每一个API接口。本实施例中，通过配置请求方法类型来区分不同的API接口，不会造成API报文的误加密、解密。

4）为API的URL路径进行请求忽略加解密还是响应忽略加解密进行配置的配置项。如图5所示，本实施例中，此配置项可以用req、res、*三种进行配置，其中，req代表对该URL的请求进行忽略、res代表对该URL的响应进行忽略、*代表请求和响应都进行忽略。由于每次请求URL都是应用程序客户端和应用程序服务端一次双向的交互，每一次应用程序客户端发出请求都有一个与之匹配的应用程序服务端响应，分开配置请求忽略、响应忽略、全忽略三种类型，可以最小颗粒度对报文传输做控制。以下是一个简单举例：

url: /download_image、reqOrRes:res；

表示对URL为download_image的API接口不进行响应加密。

S3：应用程序服务端监听配置中心的配置变化，应用程序服务端和应用程序客户端根据配置中心的配置变化进行配置更新。

如图6所示为本实施例应用程序服务端监听配置变化并实时刷新配置的流程示意图，包括如下步骤：

S31、在应用程序服务端嵌入一个配置中心的Client组件包，应用程序服务端即为配置中心的Client端。

S32、应用程序服务端启动运行，应用程序服务端通过本身存储的配置中心Server端地址，主动与配置中心的Server端连接，获取配置中心的配置信息，将这些配置加载到本地，并与配置中心Server端保持长链接。

应用程序服务端和配置中心Server端建立连接后不进行断开,应用程序服务端与配置中心Server端维持心跳感应，任何一方断线心跳会消失，由于保持长链接，应用程序服务端和配置中心Server端之间会立即发起重连，保证实时在线。

当系统的安全需求发生变化，需要变更配置中心的配置文件，以此来完成算法的切换。比如：将算法类型由SM2切换为SM4，算法的密钥需要进行更改，因应用程序服务端与配置中心Server端保持长链接，配置中心的Server端会以事件的形式，主动通知配置中心的Client端即应用程序服务端，应用程序服务端收到事件，会回调应用程序服务端中刷新配置的函数，函数中会通过建立的长链接重新从配置中心获取加解密的配置，覆盖本地的加解密配置。应用程序服务端从而能够刷新本地配置，完成本地配置和配置中心的实时同步，满足系统的安全需求。

需要说明的是，当配置中心其他内容发生变化时，例如忽略加解密的URL配置发生变化，应用程序服务端也可以和配置中心实现同步配置更新。

S33、应用程序客户端配置更新，和配置中心Server端的配置保持一致。配置中心Server端配置变化后，需要同步更改应用程序客户端的配置，并重启应用程序客户端，保证应用程序客户端的配置和配置中心Server端保持一致。

S4：应用程序服务端和应用程序客户端拦截请求或响应。

由于应用程序服务端和应用程序客户端已经创建好拦截器，并作为功能组件应用在应用程序服务端和应用程序客户端中，当有请求或响应进入应用程序服务端和应用程序客户端后，所有的请求或响应都会被拦截器所拦截。以下是对应用程序服务端和应用程序客户端拦截请求和响应的一个具体实例：

应用程序客户端：

应用程序客户端的请求经RequestInterceptors请求拦截器，被请求拦截器所拦截，在请求拦截器中可以取到当前请求的信息如请求参数、请求头等，拦截后的请求被暂停等待后续步骤的处理；

应用程序客户端的响应进入ResponseInterceptors响应拦截器，被响应拦截器所拦截，在响应拦截器中可以取到当前响应的信息如响应结果、响应头等，拦截后的响应被暂停等待后续步骤的处理。

应用程序服务端：

应用程序服务端的请求经ApiDecryptRequestBodyAdvice请求拦截器，被请求拦截器所拦截，在请求拦截器中可以取到当前请求的信息如请求参数、请求头等，拦截后的请求被暂停等待后续步骤的处理；

应用程序服务端的响应进入ApiEncryptResponseBodyAdvice响应拦截器，被响应拦截器所拦截，在响应拦截器中可以取到当前响应的信息如响应结果、响应头等，拦截后的响应被暂停等待后续步骤的处理。

S5：对拦截到的请求或响应是否执行加解密进行判断。

应用程序服务端和客户端拦截请求和响应后，需要对该请求或响应的URL判断是否执行加解密。

如图7所示，为本实施例举例拦截到的请求或响应的URL数据与加解密配置的示意图，举例的数据说明如下：

假设拦截到的请求或响应的URL数据为：拦截到的为请求req，这个请求的URL路径为/user/1，这个请求的方法类型为GET。

配置中的加解密配置项的数据为：开启了加密True，使用密钥为sfzy100000000的SM2算法，URL忽略加解密配置的配置包含了两条配置，其中，序号1的为：资源路径URL为/user/1、请求方法类型为GET、忽略请求加密req，序号2的为：资源路径URL为/user/2、请求方法类型为POST、忽略响应加密res。

执行后续判断时可以以此举例的数据为基准，对拦截到的请求或响应是否执行加解密进行判断。

如图8所示，为本实施例判断此次请求或响应是否执行加解密的流程图，包括如下步骤：

S51、在对应的请求或响应拦截器中，获取配置中是否开启加解密配置的配置项，判断该配置项的值是否为True，如果是，则执行后续的判断流程；如果不是，则不对拦截到的请求或响应进行加解密操作，结束。

S52、判断URL忽略加解密配置是否满足，判断步骤如下：

根据取到的当前请求或响应的URL的路径，逐个取出配置中URL忽略加解密的配置数据进行比对，比对是否存在对应URL路径，如果存在则继续后续判断，否则执行后续的加解密流程，结束。

如果存在对应URL路径，将该URL路径的请求方法类型、是请求还是响应，与该URL的路径对应配置中的请求方法类型和忽略加解密还是响应加解密的配置数据进行比对，存在不一致则执行后续的加解密流程，如果全部一致，则不对拦截到的请求或响应进行加解密操作，结束。

S6：对需要加解密的请求或响应执行加解密处理。

经过上述步骤的判断，如果该请求需要执行加解密，则进行以下步骤：

S61、在拦截器中根据不同的算法类型，获取配置中不同算法对应的算法密钥。

S62、在拦截器中调用不同算法实现的工具类，通过算法密钥对拦截器中拦截到的请求或响应的报文做加解密。

当系统的安全需求发生变化，如，安全等级保护发生改变或发生密钥泄露需要变更密钥，则对配置中心的server端和应用程序客户端的配置项做出相应改变后，在拦截器中会切换不同的算法或密钥对报文进行加解密。如：当算法SM2的密钥发生改变时，使用新的算法密钥对拦截到的请求或响应的报文进行加解密；当算法类型发生改变时，切换不同算法的工具类对拦截到的请求或响应的报文做加解密。

本实施例中，各类加解密算法的算法实现可以从网址GitHub中获取，并将对应的实现封装成工具类，封装好的工具类供拦截器调用。工具类是为了提供一些通用的、某一非业务领域内的公共方法，不需要配套的成员变量，仅仅是作为工具方法被使用。

加解密后的报文替换未加解密前的报文执行后续操作。完成整个加解密流程。本实施例加密后的报文为乱码传输，具备不可阅读、无法理解的特性，且加密后的报文无算法密钥无法解密，可解决报文传输中敏感信息泄露、被劫持的安全漏洞，大大增加了系统的安全性。

以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种支持多种算法切换的报文加解密方法，其特征在于包括如下步骤：

S1、在服务端与客户端创建请求拦截器和响应拦截器；

S2、在配置中心的Server端、应用程序服务端与客户端进行加解密配置；

S3、服务端监听配置中心的配置变化，服务端和客户端根据配置中心的配置变化进行配置更新；

S4、服务端和客户端拦截请求或响应；

S5、判断拦截到的请求或响应是否执行加解密；

S6、对加解密的请求或响应执行加解密处理。

2.如权利要求1所述的支持多种算法切换的报文加解密方法，其特征在于，所述在配置中心的Server端、应用程序服务端与客户端进行加解密配置包括：

1）在配置中心的Server端中，创建一个公共的加解密配置文件，用于存储加解密配置项；

2）在应用程序服务端与客户端，分别创建一个配置文件，其中：服务端配置文件存储配置中心Server端的地址和加解密配置文件；客户端配置文件中存储加解密配置项。

3.如权利要求2所述的支持多种算法切换的报文加解密方法，其特征在于，所述加解密配置项包括：为是否开启加解密进行配置的是否开启加解密配置项、为每个算法配置算法密钥的算法密钥配置项、为对不能进行加解密的API接口的URL进行忽略请求加解密配置的URL忽略请求加解密配置项。

4.如权利要求3所述的支持多种算法切换的报文加解密方法，其特征在于，在算法密钥配置项进行配置时，对算法密钥再进行一次Base64加密。

5.如权利要求3所述的支持多种算法切换的报文加解密方法，其特征在于，所述URL忽略请求加解密配置项包括：当前序号、资源路径URL、请求方法类型、忽略请求加解密还是响应加解密。

6.如权利要求1所述的支持多种算法切换的报文加解密方法，其特征在于，所述服务端监听配置中心的配置变化，服务端和客户端根据配置中心的配置变化进行配置更新包括如下步骤：

1）在应用程序服务端嵌入一个配置中心的Client组件包，应用程序服务端即为配置中心的Client端；

2）应用程序服务端启动运行，服务端通过本身存储的配置中心Server端地址，主动与配置中心的Server端连接，获取配置中心的配置信息，将这些配置加载到本地，并与配置中心Server端保持长链接；

3）应用程序客户端配置更新，和配置中心Server端的配置保持一致。

7.如权利要求1所述的支持多种算法切换的报文加解密方法，其特征在于，所述判断拦截到的请求或响应是否执行加解密包括如下步骤：

1）在对应的请求或响应拦截器中，获取配置中是否开启加解密配置的配置项，判断该配置项的值是否为True，如果是，则执行后续的判断流程；如果不是，则不对拦截到的请求或响应进行加解密操作，结束；

2）判断URL忽略请求加解密配置是否满足：根据取到的当前请求或响应的URL的路径，逐个取出配置中URL忽略请求加解密的配置数据进行比对，比对是否存在对应URL路径；如果存在对应URL路径，将该URL路径的请求方法类型、是请求还是响应，与该URL的路径对应配置中的请求方法类型和忽略请求加解密还是响应加解密的配置数据进行比对。

8.如权利要求1所述的支持多种算法切换的报文加解密方法，其特征在于，所述对加解密的请求或响应执行加解密处理包括如下步骤：

1）在拦截器中获取不同算法对应的算法密钥；

2）在拦截器中调用不同算法实现的工具类，通过算法密钥对拦截器中拦截到的请求或响应的报文做加解密。

Images