CN118041530A - 一种服务器间通信密钥升级方法及相关装置 - Google Patents

Abstract

本申请提供了一种服务器间通信密钥升级方法及相关装置，通信双方均通过配置文件维护一个或多个加密算法，每个加密算法有多个密钥。通信双方在加密通信时有多套密钥可选择。发送方只需更换密钥编号，并使用更换后的密钥编号对应的密钥进行加密，并告知接收方当前使用的密钥的编号。接收方只需使用密钥编号对应的密钥进行解密。这种情况下，接收方服务器不需要进行任何变更，发送方服务器只需要进行简单的密钥配置变更，通过管理控制台执行管理命令即可实现。通信双方不需要专门的数据库维护密钥，降低了成本，而且通信双方无需停机，因此提高了业务的持续性。

Description

一种服务器间通信密钥升级方法及相关装置

技术领域

本发明属于计算机技术领域，尤其涉及一种服务器间通信密钥升级方法及相关装置。

背景技术

在分布式系统中，特别是面向服务的架构(Service Oriented Architecture,SOA)中，作为服务使用方的客户端和作为服务提供方的服务器端通常跨越了企业的网络边界。在服务提供方内部，一个业务请求可能由多个不同服务来处理，这些服务通过定义好的接口和协议进行通信，通常分布在不同的服务器上，因此，业务处理过程必然涉及服务器间通信。

考虑到服务器间通信的安全性，通信双方通常采用加密通信方式，例如，使用加密机直接对所有报文进行加解密，此种方式对加密机的处理性能、可靠性、可用性要求非常高，需要采购专门的硬件设备，即购置成本高，而且，日常的运营成本也非常高，可见此种加密通信方式的整体成本高；或者，通信双方直接使用对称加密方式，对所有报文(或报文中的部分内容)进行加解密，此种方式通常需要使用配置文件或数据库管理加解密的密钥。若采用数据库管理密钥，需要采购专门的数据库系统，即成本高；而且，数据库会成为性能瓶颈和单点的问题，以及存在数据库系统和通信双方进行密钥交换的安全性问题。若采用配置文件管理密钥，需要对所使用的密钥进行升级，通信双方必须保持升级步调一致，这种升级通常要求通信双方同时停机或先后停机，造成业务中断。

因此，亟需一种不需要停机的密钥升级方案。

发明内容

有鉴于此，本发明的目的在于提供一种服务器间通信密钥升级方法及相关装置，以在线方式对服务器间通信密钥进行升级，不需要服务器停机，充分保持业务的连续性；不依赖于加密机和数据库，降低了成本，且提高了安全性。本申请提供的服务器间通信密钥升级方法如下：

第一方面，本申请提供了一种服务器间通信密钥升级方法，应用于通信系统，通信系统包括第一服务器和第二服务器，第一服务器为发送方服务器，第二服务器为接收方服务器，方法包括：

第一服务器利用第一编号对应的密钥对第一待发送业务数据进行加密得到第一加密报文，第一服务器维护有多个密钥，每个密钥具有一个唯一编号；

第一服务器向第二服务器发送第一加密报文；

第二服务器利用第一密钥对第一加密报文进行解密，第一密钥对应的密钥编号为第一编号；

第一服务器将当前使用的密钥由第一密钥更换为第二密钥，第二密钥对应的密钥编号为第二编号；

第一服务器利用第二密钥对第二待发送业务数据进行加密得到第二加密报文，第二加密报文包括第二编号及加密后的业务数据；

第一服务器向第二服务器发送第二加密报文；

第二服务器利用第二加密报文中的第二编号对应的密钥对第二加密报文进行解密。

第二方面，本申请还提供了一种服务器间通信密钥升级装置，包括：管理控制台、服务进程、第一配置文件和第二配置文件，第一配置文件用于存储当前正在使用的密钥信息，密钥信息包括第一编号，第二配置文件用于存储多个密钥信息，每个密钥具有一个唯一编号；

管理控制台用于向服务进程发送密钥变更命令，密钥变更命令包括第二编号，第二编号为变更后的密钥编号；

服务进程响应于密钥变更命令，将当前使用的密钥由第一密钥更换为第二密钥，第二密钥对应的密钥编号为第二编号，以及使用第一加密算法及第二编号对应的密钥对待发送业务数据进行加密得到加密报文，加密报文包括第二编号及加密后的业务数据；

服务进程向第二服务器发送加密报文，使得第二服务器基于加密报文中的第二编号对应的密钥解密加密报文。

第三方面，本申请还提供了一种服务器间通信系统，包括第一服务器和第二服务器，第一服务器为发送方服务器，第二服务器为接收方服务器；

第一服务器利用第一密钥对第一待发送业务数据进行加密得到第一加密报文，第一密钥对应的密钥编号为第一编号，第一服务器维护有多个密钥，每个密钥具有一个唯一编号；

第一服务器向第二服务器发送第一加密报文；

第二服务器利用第一密钥对第一加密报文进行解密；

第一服务器将当前使用的密钥由第一密钥更换为第二密钥，第二密钥对应的密钥编号为第二编号；

第一服务器利用第二密钥对第二待发送业务数据进行加密得到第二加密报文，第二加密报文包括第二编号及加密后的业务数据；

第一服务器向第二服务器发送第二加密报文；

第二服务器利用第二加密报文中第二编号对应的密钥对第二加密报文进行解密。

第四方面，本申请还提供了一种电子设备，所述电子设备包括：一个或多个处理器、存储器和触摸屏；所述存储器用于存储程序代码；所述处理器用于运行所述程序代码，使得所述电子设备实现如第一方面任一项所述的服务器间通信密钥升级方法。

第五方面，本申请还提供了一种计算机可读存储介质，其上存储有指令，当所述指令在服务器上运行时，使得所述服务器执行如第一方面任一项所述的服务器间通信密钥升级方法。

第六方面，本申请还提供了一种计算机程序产品，其上存储有指令，当该计算机程序产品在服务器上运行时，使得该服务器执行如第一方面任一项所述的服务器间通信密钥升级方法。

本实施例提供的服务器间通信密钥升级方法，通信双方均通过配置文件维护一个或多个加密算法，每个加密算法有多个密钥。通信双方在加密通信时有多套密钥可选择。发送方只需更换密钥编号，并使用更换后的密钥编号对应的密钥进行加密，并告知接收方当前使用的密钥的编号。接收方只需使用密钥编号对应的密钥进行解密。这种情况下，接收方服务器不需要进行任何变更，发送方服务器只需要进行简单的密钥配置变更，通过管理控制台执行管理命令即可实现。通信双方不需要专门的数据库维护密钥，降低了成本，而且通信双方无需停机，因此提高了业务的持续性。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1是本申请实施例提供的一种服务器间通信系统的结构示意图；

图2是本申请实施例提供的一种服务器间通信密钥升级方法的流程图；

图3是本申请实施例提供的另一种服务器间通信密钥升级方法的流程图；

图4是本申请实施例提供的又一种服务器间通信密钥升级方法的流程图；

图5是本申请实施例提供的又一种服务器间通信密钥升级方法的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

为了下述各实施例的描述清楚简洁，首先给出相关技术的简要介绍：

分布式系统：由一些独立的系统集合组成，通过网络实现信息交换和资源共享，像一个整体一样运行的系统。具有高度的内聚性和透明性，用户只需与整个系统交互，无需关心各个组成部分的具体实现。

面向服务的架构(SOA架构)：是一种粗粒度、松耦合的服务架构。服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型，将应用程序的不同功能单元(或称为服务)通过服务之间定义好的接口和协议联系起来。

加密：一种保护数据安全的技术，通过使用密钥和加密算法将明文转换为密文，使得未经授权的用户无法解密和访问原始数据。

解密：将密文转换为明文的过程，是加密的逆过程。

密钥：是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥。

对称加密：也称为单密钥加密，其中一个密钥可以同时用于加密和解密信息。常见的有AES，DES等方法。

加密机：是一种通过国家商用密码主管部门鉴定并批准使用的国内自主开发的主机加密设备。它主要的功能模块包括硬件加密部件，这个部件主要实现各种密码算法，安全保存密钥，例如CA的根密钥等。加密机和主机之间使用TCP/IP协议通信，所以加密机对主机的类型和主机操作系统无任何特殊的要求。

请参见图1，示出了本申请实施例提供的一种服务器间通信系统的结构示意图。本实施例以两个服务器之间进行通信为例进行说明，在包含多个服务器的系统中任意两个服务器之间可以进行通信，其本质仍是两个服务器之间进行通信。

如图1所示，每个服务器均包括管理控制台、服务进程和密钥配置文件。

例如，密钥配置文件(即第二配置文件)，用于存储所有加密算法(如所有加密算法可以是一个或多个)及对应的密钥，每个加密算法具有多个密钥，每个密钥具有一个唯一编号，即密钥编号；每个加密算法具有一个唯一代号，即算法代号。密钥配置文件用于存储服务器间加密通信时所使用的加解密算法代号、密钥编号及密钥。该配置文件中存储有上述三种信息的三元组组成的有序集合。

通信双方维护的密钥配置文件相同，这样才能保证双方使用相同的密钥进行加解密。如本实施例中，密钥配置文件A和密钥配置文件B维护的密钥相同。

在本申请一示例性实施例中，若加密通信过程可以采用多种加密算法，则可有多个存放密钥配置的配置文件，如一个加密算法对应一个密钥配置文件。

示例性的，每个密钥配置文件包括多个密钥记录，每个密钥记录包括密钥编号及密钥。

例如，如下示出了AES算法的密钥配置片段：

#KeyList-AES

1

QmFpSml1WGluU2h1U2hhblpob25nR3VpSHVhbmdKaVo＝

2

aHVvU2h1UWl1WmhlbmdGZWlIdVRvbmdQZW5nSmlaaHU＝

...

65536

b0JhaUppdUVyTnZYaVhpYW9RaWFuUmVuWWlHYW9HZVE＝

如下示出了SM4算法的密钥配置片段：

#KeyList-SM4

1

dVp1aVl1WmlXZWlRaVd1THVvUmlaaGVuZ0d1YW5nSHU＝

2

aVlvdVNodWlXYW5TaGVuZ0t1QnVaYW9aaHVvQmlhbks＝

...

32768

dWFNYVNoZVl1YW5EYW9LdWFpSmlZdUZ1UWluZ01haUM＝

上述的密钥配置片段中，以“#”开头的为注释行，如“#KeyList-SM4”表示SM4算法的密钥配置，“#KeyList-AES”表示AES算法的密钥配置。密钥配置文件中除空白行和注释行之外均为密钥记录，每个密钥记录中，密钥编号可以独占一行；配置文件中的密钥可以是加密并文本化(例如，进行BASE64编码)后的密钥。密钥编号可从1开始连续编号，不重复、不遗漏。

本文仅以AES算法和SM4算法为例进行说明，实际应用中还可以采用其他加密算法，本申请对加密算法的类型不做限定。

服务进程用于进行业务处理，包括与其他服务器进行通信，在本发明中可作为报文发送方、报文接收方。报文发送方和报文接收方位于不同的服务器上，两者之间的通信为服务器间通信。在通信过程中，服务进程根据不同服务的业务处理要求的不同，可以对于全部报文的全部内容、部分报文的全部内容、部分报文的部分内容进行加解密。作为报文发送方的服务进程完成内容加密过程，作为报文接收方的服务进程完成报文解密过程。

管理控制台，用于管理密钥配置和服务进程。只有高级别的系统维护人员或受信任的系统在获得授权后才能在管理控制台进行操作。管理控制台中的任何操作都记录详细的审计日志。可以通过服务器中的管理控制台，以在线的方式设定服务进程作为报文发送方进行报文加密时所使用加密算法、所使用的密钥对应的编号，满足更换通信密钥的需求。进一步地，可以通过管理控制台更新单个当前未使用的密钥，或重新加载全部密钥配置(当前正在使用的密钥保持不变)等操作，满足一定时期后避免使用重复通信密钥的需求。

本申请中，服务器间通信双方进行加密通信时，发送方可以选择其中任一个加解密算法的任一个密钥进行加密。为每一个加解密算法配置多个密钥，增大了服务器间通信双方的密钥选择范围。

报文发送方的加密工作是主动的，可以自主指定使用的加解密算法、密钥。只要能够以在线的方式，让报文发送方改变所使用的密钥(或者同时变更加解密算法和密钥)，就能达到不停机地进行服务器间通信密钥升级的目的。

报文接收方的解密工作是被动的，使用的加解密算法、密钥完全由报文发送方指定。只需要确保报文接收方能够识别报文发送方指定的加解密算法代号、密钥编号，通信双方对于加解密算法代号对应的加解密算法、密钥编号对应的密钥保持一致，报文的解密工作就能顺利进行。在通信双方的密钥配置相同的情况下，只要报文发送方指定的加解密算法代号、密钥编号，报文发送方更换加解密算法、更换密钥，报文接收方都不需要进行变更。

对于更换单个密钥的场景，由于通信双方在通信时有多套密钥可供选择，发送方只需更换密钥编号、并使用更换后的密钥编号对应的密钥进行加密，并告知接收方当前使用的密钥的编号。接收方只需使用密钥编号对应的密钥进行解密。这种情况下，接收方服务器不需要进行任何变更，发送方服务器只需要进行简单的密钥配置变更，通过管理控制台执行管理命令即可实现。

对于整套密钥配置的替换升级，只需要保持通信双方当前正在使用的密钥不变，其他的密钥都可以进行修改；通信双方的修改不需要同时进行，不需要停机，只通过管理控制台执行相应的管理命令即可实现。

在本申请一示例性实施例中，系统维护人员或受信任的系统在获得授权后，可以通过管理控制台，使用管理命令对密钥配置文件和服务进程进行管理，主要包括如表1所示的管理命令：

表1

下面将分别针对不同的场景介绍本申请提供的服务器间通信密钥升级方法。

场景一：不停机，更换当前使用的密钥

请参见图2，示出了本申请实施例提供的一种服务器间通信密钥升级方法的流程图，该方法可以更换通信双方当前使用的密钥。例如，当前使用密钥编号n对应的密钥加密，通过该方法可以更换为使用m对应的密钥加密。

本实施例中，服务器A为发送方服务器，服务器B为接收方服务器。如图2所示，该方法可以包括如下步骤：

S101，服务进程A进行业务处理。

服务器A中的服务进程A进行相应的业务处理，如解析客户端发送的业务请求等，本申请对业务处理的具体内容不作限定。

S102，服务进程A使用第一编号对应的密钥对业务数据进行加密得到第一加密报文。

设通信系统支持M种加密算法用于通信加密，每一种加密算法具有一个唯一的算法代号，如算法代号可以从1开始编号，第i种加密算法对应的算法代号为i，i为正整数，1≤i≤M。密钥配置文件中存储每一种加密算法对应的Ni个密钥，Ni≥2，不同的加密算法可以有不同数量的密钥，即不同算法对应的Ni不同。

服务进程A使用代号为i的加密算法中编号为n(1≤n≤Ni)的密钥对需加密的内容进行加密。

示例性的，服务器A从其他密钥变更至第一编号对应的密钥进行加密(或首次使用该密钥)时，可以在加密报文中添加当前使用的加密算法代号和密钥编号，从而使服务器B获知当前使用的密钥并更新至服务器B的第一配置文件中。在后续的加密通信过程中，服务A发送的加密报文中无需添加当前使用的算法代号和密钥编号。

S103，服务进程A向服务器B发送第一加密报文。

S104，服务器B使用第一配置文件中的算法代号及密钥编号对应的密钥对第一加密报文进行解密。

服务器B中的服务进程接收到第一加密报文后进行解析，若第一加密报文包含算法代号及密钥编号，进一步利用算法代号及密钥编号对应的密钥解密第一加密报文中的加密内容。若第一加密报文中不包含算法代号及密钥编号，则直接使用服务器B的第一配置文件记录的算法代号及密钥编号对应的密钥对第一加密报文进行解密。

S105，服务器B基于解密得到的业务数据进行相应的业务处理。

上述S101～S105所述的过程是服务器A和B均采用第一加密算法中第一编号对应的密钥进行加密通信。

S106，服务器A中的管理控制台A向服务进程A发送密钥变更命令。该密钥变更命令包括变更后的密钥编号，如第二编号。

管理控制台接收到变更当前使用的密钥的指令(如，接收到系统维护人员或受信任的系统在服务器A上发起的变更密钥的指令)后，

示例性的，管理控制台可以提供用户交互界面，系统维护人员可在交互界面点击变更密钥的按钮，进一步交互界面可显示可选择的密钥编号，用户从可选密钥编号中选择一个编号作为下一次加密使用的密钥，经过上述过程管理控制台生成密钥变更命令并发送至服务进程A。此外，还可以由受信任的系统自动触发上述的密钥变更过程，受信任的系统向管理控制台发送触发其变更密钥的指令，管理控制台响应于该指令可以随机选择一个密钥编号，并生成密钥变更命令。

示例性的，密钥变更命令可以是表1中的updateKeyIndex命令。例如，密钥变更命令如下：

>updateKeyIndex-v 30

updateKeyIndex OK，Saved to serviceA.dat！

上述命令表示将密钥编号更新为30，管理控制台判定变更后的密钥编号处于当前加密算法对应的密钥编号范围内，确定变更成功，同时触发服务进程更新第一配置文件，即示例中的配置文件serviceA.dat。

若管理控制台判定变更后的密钥编号超出密钥配置文件中的密钥编号范围，则确定密钥变更失败，并报错，对应的命令行如下：

>updateKeyIndex-v 30

updateKeyIndex failed！

在只更换密钥的场景中，密钥变更命令中只需携带变更后的密钥编号，服务进程基于该密钥变更命令将命令中的密钥编号更新至服务进程的内存及第一配置文件中。

由于服务器A和服务器B更新密钥配置文件可以分别独立修改，即两者修改密钥配置文件的时间可以不同，只需在使用密钥配置文件时确保两者一致即可，例如，在变更当前使用的密钥编号时，确保通信双方的密钥配置文件一致才执行该密钥变更命令，如果不一致则不变更密钥编号。

S107，服务进程A向服务器B中的服务进程B发送一致性校验请求。

该一致性校验请求用于请求校验服务器A和服务器B中的密钥配置文件是否一致。

S108，服务器B响应于一致性校验请求向服务器A返回密钥配置文件的第一校验码。

例如，第一校验码可以是MD5校验码，也可以采用其他校验码，如CRC校验码，本申请对此不做限定。

S109，服务器A比较第一校验码与本地的密钥配置文件的第二校验码是否一致。如果不一致，则执行S110；如果一致，则执行S111。

例如，服务器A比较服务器B发送的第一校验码与根据本地的密钥配置文件获得的第二校验码是否相同，若两个校验码相同，则表明通信双方的密钥配置文件的内容一致。若两个校验码不同则表明通信双方的密钥配置文件的内容不一致。

S110，服务进程A向管理控制台A返回错误信息。

服务进程A确定服务器A和服务器B的密钥配置文件不一致后，不执行密钥变更命令，即仍使用当前正在使用的密钥进行加密通信，同时，向管理控制台返回错误信息，以使系统维护人员或受信任的系统重新更新通信双方的密钥配置文件。

S111，服务进程A响应于密钥变更命令，将第二编号更新至服务进程A的内存及第一配置文件中。

第一配置文件是服务进程维护的用于存储发送报文时所使用的加密算法代号、密钥编号及对应的密钥。

在一示例性实施例中，服务进程A在启动时会基于第一配置文件获得当前使用的密钥信息(如，加密算法代号、密钥编号及密钥)加载至服务进程A的内存中，后续在进行加密通信时，直接从内存中读取要使用的密钥。内存读取速度大于磁盘读取速度，提高了加密通信的效率。

此种场景下，当服务进程A接收到管理控制台下发的密钥变更命令后，且确定通信双方的密钥配置文件一致后，执行密钥变更命令，即需要更新内存中的密钥信息，从而保证下一次加密通信时，可以从内存中读取变更后的密钥信息。同时，也需要更新第一配置文件中的密钥信息，从而保证服务进程重启内存中的密钥信息丢失，此时需要重新将第一配置文件中的密钥信息加载至内存。因此，第一配置文件中的密钥信息需保持最新状态。

例如，当服务进程接收到管理控制台发送的密钥变更命令后，将该命令携带的算法代号和密钥编号更新至服务进程的内存及第一配置文件中。进一步，服务进程可以从第二配置文件中查找第二编号对应的密钥加载至内存中。

第二配置文件即图1所示的配置文件，用来维护服务器所使用的全部加密算法及对应的密钥。该第二配置文件可以包括多个文件，如每个加密算法对应一个配置文件。

后续服务进程进行加密通信时会利用最新的密钥编号对应的密钥对待加密内容进行加密。

示例性的，第一配置文件的片段如下：

Encoding＝1；

KeyIndex＝30；

KeyList＝1/aes.dat；2/sm4.dat

其中，Encoding用于标识加密算法，通信系统同时支持多种加密算法时，使用此字段标识所使用的加密算法，取值为数字，可扩充。示例性的，1表示AES算法，2表示SM4算法。

KeyIndex用于标识当前使用的加密密钥对应的编号，本示例中，使用AES加密算法，同时使用aes.dat中编号为30的密钥进行加密。

KeyList指示密钥配置文件对应关系，每组对应关系包括加密算法代号、密钥配置文件名，两者使用“/”分隔。各组对应关系之间使用“；”分隔。例如，“1/aes.dat”表示AES算法的密钥配置文件为aes.dat；“2/sm4.dat”表示SM4算法的密钥配置文件为sm4.dat。

S112，服务进程A向管理控制台A发送更新成功的响应消息。

服务进程A更新完第一配置文件中的密钥信息后，可以向管理控制台返回更新成功的响应消息。

在本申请的其它实施例中，若服务进程更新内存或第一配置文件的过程失败，则服务进程可以向管理控制台返回更新失败的响应消息。或者，管理控制台在发送密钥变更命令后预设时长内未收到服务进程返回的任何响应消息则判定服务进程更新密钥失败。

S113，服务进程A进行相应的业务处理。

服务进程A接收到需要处理的业务数据。

S114，服务进程A使用第二编号对应的密钥对业务数据进行加密得到第二加密报文。

服务进程A使用变更后的密钥编号对应的密钥对新接收到的业务数据进行加密，同时，将算法代号及密钥编号添加至加密报文中得到第二加密报文。即第二加密报文包括加密后的业务数据，以及更换后的密钥信息，使得服务器B获知更换后的密钥信息。

示例性的，服务进程A生成的报文示例如下，包含加密算法代号encoding(值为1)、所使用的密钥编号keyIndex(值为30)、加密内容pass、其他内容(如果有的话，此处为trace，username，ver等)：

{“encoding”:”1”,keyIndex:”30”,trace:”1”,username:”np2008221”,”ver”:”2”,”pass”:”eFr46i42ZKNiVrEYeTY9BIszTkr6sSwL6d2Da/QKwwY＝”}

在一示例性实施例中，只需在变更密钥后的首次加密报文中携带变更后的密钥信息，从而使接收方获知变更后的密钥信息，并使用新密钥进行解密。后续的加密报文中无需添加该密钥信息。

S115，服务进程A向服务器B发送第二加密报文。

S116，服务器B解析第二加密报文获得变更后的第二编号，并使用第二编号对应的密钥解密第二加密报文。

服务器B解析接收到的第二加密报文，若解析结果包含变更后的密钥信息，如算法代号及密钥编号(如第二编号)，则比较解析得到的算法代号与第一配置文件中记录的算法代号是否相同，若相同，则继续比较解析得到的密钥编号与第一配置文件中记录的密钥编号是否相同，若不同，则从第二配置文件中查找与第二编号对应的密钥，并利用该密钥解密第二加密报文。

S117，服务器B对解密后的业务数据进行相应的业务处理。

S118，服务器B将变更后的密钥信息更新至第一配置文件。

服务器B中的服务进程进行成功解密第二加密报文后，将解析第二加密报文所使用的密钥信息更新至服务进程B的内存及第一配置文件中，也即，将第二加密报文携带的算法代号及密钥编号(即第二编号)存储至第一配置文件中。这样，服务器B可以直接从内存或第一配置文件中获得解密密钥信息，无需服务器A每次发送的报文中携带密钥信息，提高了加密通信的安全性。

本实施例提供的服务器间通信密钥升级方法，通信双方均通过配置文件维护一个或多个加密算法，每个加密算法有多个密钥。通信双方在加密通信时有多套密钥可选择。发送方只需更换密钥编号，并使用更换后的密钥编号对应的密钥进行加密，并告知接收方当前使用的密钥的编号。接收方只需使用密钥编号对应的密钥进行解密。这种情况下，接收方服务器不需要进行任何变更，发送方服务器只需要进行简单的密钥配置变更，通过管理控制台执行管理命令即可实现。通信双方不需要专门的数据库维护密钥，降低了成本，而且通信双方无需停机，因此提高了业务的持续性。而且，该方案在变换密钥编号之前先确认通信双方的密钥配置文件是否一致，如果一致才会变更当前使用的密钥编号，从而确保通信双方变更后的密钥相同，确保双方可以正常进行加密通信。

场景二：不停机，更换当前使用的加密算法

该实施例适用于加密通信双方具有至少两种加密算法的场景，具体的，更换通信双方当前使用的加密算法，例如，当前使用算法代号为1的加密算法，通过该方法可变更为使用代号为2的加密算法。

请参见图3，示出了本申请实施例提供的另一种服务器间通信密钥升级方法的流程图，如图3所示，该方法可以包括如下步骤：

S201，服务器A中的服务进程A进行业务处理。

S202，服务进程A使用第一加密算法及第一密钥对业务数据进行加密得到第一加密报文。

第一加密算法对应的算法代号为第一代号，第一密钥对应的密钥编号为第一编号。

S203，服务进程A向服务器B发送第一加密报文。

S204，服务器B使用第一解密算法及第一密钥对第一加密报文进行解密得到解密后的业务数据。

S205，服务器B对解密后的业务数据进行相应的业务处理。

S201～S205所述的过程与图2中的S101～S105所述的过程相同，此处不再赘述。

S206，管理控制台A向服务进程A发送加密算法变更命令。该命令包括变更后的算法代号(即第二代号)和密钥编号(即第三编号)。

系统维护人员或受信任的系统得到授权后，通过管理控制台A向服务进程A发布加密算法变更命令，更新加密算法代号并指定密钥编号。

管理控制台A生成加密算法变更命令的过程与生成密钥变更命令的过程相同，此处不再赘述。

例如，加密算法变更命令可以是表1中的updateEncoding命令，例如，加密算法变更命令如下：

>updateEncoding-e 2-v 40

updateEncoding OK,Saved to serviceA.dat！

上述命令表示将算法代号更新为2，指定的密钥编号为40，后续的加密通信采用算法代号2，密钥编号40对应的密钥对业务数据进行加密。管理控制台判定算法代号及密钥编号均在预设范围内，则确定变更成功，同时出发服务进程更新第一配置文件，即将该命令中的算法代号和密钥编号更新至配置文件serviceA.dat中。

若管理控制台判定变更后的算法代号超出相应的算法代号范围，和/或，密钥编号超出密钥配置文件中的密钥编号范围，则确定加密算法变更失败，并报错，对应的命令行如下：

>updateEncoding-e 3-v 40

updateEncoding failed！

假设服务器A中算法代号包括1和2，而该命令中的算法代号为3，显然，3超出了算法代号最大值2，因此，确定算法代号超出了算法代号范围，加密算法变更失败。

与场景一相同，在执行加密算法变更命令之前，先判断通信双方的密钥配置文件是否一致，即服务进程A接收到加密算法变更命令后先执行S207。

S207，服务进程A向服务器B中的服务进程B发送一致性校验请求。

S208，服务器B响应于一致性校验请求向服务器A返回密钥配置文件的第一校验码。

S209，服务器A比较第一校验码与本地的密钥配置文件的第二校验码是否一致。如果不一致，则执行S210；如果一致，则执行S211。

S210，服务进程A向管理控制台A返回错误信息。

其中，S207～S210与场景一种的S107～S110相同，此处不再赘述。

S211，服务进程A响应于加密算法变更命令，将第二代号和第三编号更新至内存及第一配置文件。

此步骤即将加密算法变更命令中的加密算法代号及密钥编号更新至服务进程A的内存及第一配置文件中。内存及第一配置文件的更新状态可以不同时进行，例如，可以先更新内存再更新第一配置文件。

S212，服务进程A向管理控制台A发送更新成功的响应消息。

S213，服务进程A进行相应的业务处理。

S214，服务进程A使用第二代号对应的加密算法及第三编号对应的密钥对业务数据进行加密得到第二加密报文。

第二加密报文携带第二代号和第三编号，从而使服务器B获知更换后的密钥信息，即加密算法代号及密钥编号。

示例性的，服务进程A生成的报文示例如下：

{“encoding”:”2”,keyIndex:”40”,trace:”1”,username:”np2008221”,”ver”:”2”,”pass”:”r2ewbQiFpN2EfeqIyThyHgo1f2KAZDPtnsH62t4SKQ＝”}

其中包含加密算法代号encoding(值为2)、所使用的密钥编号keyIndex(值为40)、加密内容pass、其他内容(此处为trace,username,ver等)

在一示例性实施例中，只需在变更加密算法后首次发送的加密报文中携带变更后的密钥信息，从而使接收方获知变更后的密钥信息，并使用新密钥进行解密。后续的加密报文中无需添加该密钥信息。

S215，服务进程A向服务器B发送第二加密报文。

S216，服务器B解析第二加密报文获得变更后的第二代号和第三编号，并使用第二代号对应的解密算法及第三编号对应的密钥解密第二加密报文。

S217，服务器B对解密后的业务数据进行相应的业务处理。

S218，服务器B将变更后的加密算法信息更新至内存及第一配置文件。

此过程即服务器B将解析第二加密报文获得的第二代号、第三编号，更新至服务器B的内存及第一配置文件中。后续服务器B可以直接使用变更后的密钥信息对接收到的加密报文进行解密。

S206～S218所述的过程与图1中S106～S118相似，本实施例不再赘述。

本实施例提供的服务器间通信密钥升级方法，通信双方均通过配置文件维护至少两个加密算法，每个加密算法有多个密钥。通信双方在加密通信时有多套密钥可选择。发送方还可以更换加密算法，并使用更换后的加密算法及指定的密钥编号对应的密钥进行加密，并告知接收方当前使用的加密算法的代号及密钥的编号。接收方只需使用相同代号的解密算法及相同密钥编号对应的密钥进行解密。这种情况下，接收方服务器不需要进行任何变更，发送方服务器只需要进行简单的密钥配置变更，通过管理控制台执行管理命令即可实现。通信双方不需要专门的数据库维护密钥，降低了成本，而且通信双方无需停机，因此提高了业务的持续性。而且，该方案在变换加密算法之前先确认通信双方的密钥配置文件是否一致，如果一致才会变更当前使用的加密算法，从而确保通信双方变更后的密钥相同，确保双方可以正常进行加密通信。

场景三：不停机，更新密钥配置文件

该场景是指通信双方的服务器在不停机的情况下，更新除当前使用的密钥之外的全部密钥配置。

请参见图4，示出了本申请实施例提供的又一种服务器间通信密钥升级方法的流程图，该方法可包括如下步骤：

S301，服务器A中的管理控制台A向服务进程A发送密钥配置文件更新命令。

受信任的系统或得到授权的系统维护人员可以通过管理控制台A发起密钥配置文件更新指令，管理控制台A接收到该指令后生成密钥配置文件更新命令(如表1中的ReloadKeyFile命令)并发送至服务进程A。该命令用于使服务进程重新加载除当前使用的密钥编号之外的其他密钥编号对应的更新后的密钥配置文件。

示例性的，密钥配置文件更新命令如下：

>ReloadKeyFile-f key.dat-x exclude.dat

ReloadKeyFile OK！

该命令用于使服务进程重新加载更新后的密钥配置文件key.dat，供后续使用，而且，排除exclude.dat文件中列明的密钥编号(其中包含当前正在使用的密钥编号)。

S302，服务进程A响应于密钥配置文件更新命令重新加载第二配置文件。

第二配置文件即新的密钥配置文件，该配置文件可以是受信任的系统下发，或者，系统维护人员手动下发。而且，下发给服务器A和服务器B的新的密钥配置文件完全相同。

S303，服务进程A向管理控制台A发送更新响应消息。

若服务进程A成功加载新的密钥配置文件，则向管理控制台A返回更新成功的响应消息。若服务进程A加载新的密钥配置文件失败，则向管理控制台返回更新失败的响应消息。

S304，服务器B中的管理控制台B向服务进程B发送密钥配置文件更新命令。

S305，服务进程B响应于密钥配置文件更新命令重新加载第二配置文件。

S306，服务进程B向管理控制台B发送更新响应消息。

S304～S306所示服务器B更新密钥配置文件的过程与S301～S303相同，此处不再赘述。作为通信双方的服务器A和服务器B执行相同的命令，从而保证通信双方的密钥配置文件处于一致状态，但并不限定服务器A和服务器B执行ReloadKeyFile命令的时机，双方可以分别在不同的时刻执行该命令，只需在更换密钥时，两个配置文件的状态一致即可。

发送方服务器确定双方的密钥配置处于一致状态后，可以安全地使用updateKeyIndex命令将当前使用的密钥编号修改为ReloadKeyFile中密钥更新后的某个密钥编号。例如，当前使用密钥编号n的密钥，更新密钥配置文件时，更新除n之外的其他全部编号对应的密钥。通信双方的密钥配置文件处于一致状态后，可以将密钥编号从n变更为m，然后使用updateKey命令或再次使用ReloadKeyFile命令更新编号n对应的密钥，从而完成所有密钥的更新过程，即图2中S107～S116所示的过程。

待全部密钥更新完成后，而且通信双方的密钥配置文件一致后可以利用updateKeyIndex命令更换当前使用的密钥变换，变更密钥的过程与图2所示的密钥变更过程相同，此处不再赘述。

此外，在确定通信双方的密钥配置文件完全一致后，可以使用updateEncoding命令更换当前使用的加密算法，变更加密算法的过程与图3所示的过程相同，此处不再赘述。

本实施例提供的服务器间通信密钥升级方法，支持密钥配置的在线更新，满足一定时期内不使用重复密钥的安全性要求，而且不影响当前系统的运行，不需要通信双方停机。除保持通信双方当前正在使用的密码不变外，其他的密码都可以进行修改而不对当前系统造成任何影响，通信双方的修改不需要同时进行，从而提高了服务器间通信的可持续性。

场景四：不停机，修改指定密钥编号对应的密钥

例如，当前正在使用编码n对应的密钥，可以使用updateKey命令修改除密钥编号n之外的任一个密钥编号对应的密钥，此过程不影响当前通信系统。

请参见图5，示出了本申请实施例提供的又一种服务器间通信密钥升级方法的流程图，该方法可包括如下步骤：

S401，服务器A中的管理控制台A向服务进程A发送密钥更新命令。

示例性的，密钥更新命令可以是updateKey命令，该命令包括指定密钥编号，即要修改的密钥编号，例如密钥编号m。指定密钥编号不能是当前正在使用的密钥编号。

例如，>updateKey-e 2-v 40-key NewKey

updateKey OK,saved to sm4.dat！

上述命令表示将算法代号为“2”(如表示SM4算法)、指定密钥编号为“40”对应的密钥更新为新密钥，其中，“NewKey”表示新密钥的具体内容，更新成功则将新密钥存储至密钥配置文件sm4.dat中。

S402，服务进程A响应于密钥更新命令，将第二配置文件中指定密钥编号对应的密钥修改为目标密钥。

目标密钥可以由受信任的系统自动下发，或者由得到授权的系统维护人员手动下发。

S403，服务进程A向管理控制台A发送密钥更新响应消息。

若服务进程A成功修改指定密钥编号对应的密钥，则向管理控制台A返回更新成功的响应消息。若服务进程A修改指定密钥编号对应的密钥失败，则向管理控制台返回更新失败的响应消息。

S404，服务器B中的管理控制台B向服务进程B发送密钥更新命令。

作为通信双方的服务器A和服务器B执行相同的命令，从而保证通信双方的密钥保持一致。而且，可以由受信任的系统自动向服务器下发目标密钥，或者由得到授权的系统维护人员手动下发目标密钥，从而保证通信双方收到的指定密钥编号对应的目标密钥相同。

S405，服务进程B响应于密钥更新命令，将第二配置文件中指定密钥编号对应的密钥修改为目标密钥。

S406，服务进程B向管理控制台B发送密钥更新响应消息。

S404～S406所示的过程是修改服务器B侧的指定密钥编号的密钥的过程，与S401～S403所示过程相同，此处不再赘述。

在一种应用场景中，前述的密钥配置文件更新命令(ReloadKeyFile命令)无法更新当前正在使用的密钥编号对应的密钥，因此可以在使用ReloadKeyFile命令更新密钥配置文件后，继续使用本实施例提供的密钥更新命令(updateKey命令)更新未更新的密钥编号对应的密钥。当然，也可以在其他场景中使用该密钥更新命令，本申请对使用密钥更新命令的具体使用场景不做具体限定。

发送方服务器确定自身与接收方服务器侧的密钥配置文件状态一致后，可以使用updateKeyIndex命令更换当前使用的密钥编号，或者，使用updateEncoding命令更换当前使用的加密算法，更换过程与图2和图3所示的实施例相同，此处不再赘述。

本实施例提供的服务器间通信密钥升级方法，在不影响通信双方服务器通信的情况下，可以通过密钥更新命令更新单个密钥编号对应的密钥，通信双方的修改不需要同时进行，而且不需要停机。

本申请提供了一种电子设备，该电子设备包括处理器和存储器，该存储器内存储有可在处理器上运行的程序。该处理器运行存储器内存储的该程序时实现上述的服务器间通信密钥升级方法。本文中的电子设备可以是单个服务器，或包括多个服务器的服务器集群。

本申请还提供了一种计算机可执行的存储介质，该存储介质中存储有程序，该程序由电子设备执行时实现上述的服务器间通信密钥升级方法。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

在一些实施方式中，客户端、服务器可以利用诸如HTTP(Hyper Text TransferProtocol，超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

另一方面，本申请实施例还提供了一种计算机存储介质，其上存储有指令，当该指令在服务器上运行时，使得服务器执行如下：

第一服务器利用第一编号对应的密钥对第一待发送业务数据进行加密得到第一加密报文，第一服务器维护有多个密钥，每个密钥具有一个唯一编号；

第一服务器向第二服务器发送第一加密报文；

第二服务器利用第一密钥对第一加密报文进行解密，第一密钥对应的密钥编号为第一编号；

第一服务器将当前使用的密钥由第一密钥更换为第二密钥，第二密钥对应的密钥编号为第二编号；

第一服务器利用第二密钥对第二待发送业务数据进行加密得到第二加密报文，第二加密报文包括第二编号及加密后的业务数据；

第一服务器向第二服务器发送第二加密报文；

第二服务器利用第二加密报文中的第二编号对应的密钥对第二加密报文进行解密。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

又一方面，本申请还提供了一种计算机程序产品，该计算机程序产品，其上存储有指令，当该计算机程序产品在服务器上运行时，使得该服务器执行如下方法：

第一服务器利用第一编号对应的密钥对第一待发送业务数据进行加密得到第一加密报文，第一服务器维护有多个密钥，每个密钥具有一个唯一编号；

第一服务器向第二服务器发送第一加密报文；

第二服务器利用第一密钥对第一加密报文进行解密，第一密钥对应的密钥编号为第一编号；

第一服务器将当前使用的密钥由第一密钥更换为第二密钥，第二密钥对应的密钥编号为第二编号；

第一服务器利用第二密钥对第二待发送业务数据进行加密得到第二加密报文，第二加密报文包括第二编号及加密后的业务数据；

第一服务器向第二服务器发送第二加密报文；

第二服务器利用第二加密报文中的第二编号对应的密钥对第二加密报文进行解密。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (12)

1.一种服务器间通信密钥升级方法，其特征在于，应用于通信系统，所述通信系统包括第一服务器和第二服务器，所述第一服务器为发送方服务器，所述第二服务器为接收方服务器，所述方法包括：

所述第一服务器利用第一编号对应的密钥对第一待发送业务数据进行加密得到第一加密报文，所述第一服务器维护有多个密钥，每个密钥具有一个唯一编号；

所述第一服务器向第二服务器发送所述第一加密报文；

所述第二服务器利用所述第一密钥对所述第一加密报文进行解密，所述第一密钥对应的密钥编号为第一编号；

所述第一服务器将当前使用的密钥由所述第一密钥更换为第二密钥，所述第二密钥对应的密钥编号为第二编号；

所述第一服务器利用所述第二密钥对第二待发送业务数据进行加密得到第二加密报文，所述第二加密报文包括所述第二编号及加密后的业务数据；

所述第一服务器向所述第二服务器发送所述第二加密报文；

所述第二服务器利用所述第二加密报文中的所述第二编号对应的密钥对所述第二加密报文进行解密。

2.根据权利要求1所述的方法，其特征在于，所述第一服务器将当前使用的密钥由所述第一密钥更换为第二密钥，包括：

所述第一服务器获取密钥变更命令，所述密钥变更命令包括第二编号，所述第二编号为变更后的密钥编号；

所述第一服务器响应于所述密钥变更命令，将所述第一服务器内存及第一配置文件中的存储密钥编号更新为所述第二编号，所述第一配置文件用于存储当前使用的密钥信息。

3.根据权利要求1或2所述的方法，其特征在于，所述第一服务器利用所述第二密钥对第二待发送业务数据进行加密得到第二加密报文，包括：

所述第一服务器从第二配置文件中查找与所述第二编号对应的密钥，所述第二配置文件用于存储所有加密算法及密钥的信息；

所述第一服务器利用所述第二编号对应的密钥对所述第二待发送业务数据进行加密，得到第二加密报文。

4.根据权利要求1所述的方法，其特征在于，所述第一服务器维护有至少两个加密算法，每个加密算法具有一个唯一代号，每个加密算法具有多个密钥，所述第一服务器将当前使用的密钥由所述第一密钥更换为第二密钥，包括：

所述第一服务器获取加密算法变更命令，所述加密算法变更命令包括第二密钥对应的第二代号及密钥对应的第三编号；

所述第一服务器响应于所述加密算法变更命令，将所述第一服务器的内存及第一配置文件中存储的算法代号由第一代号更新为所述第二代号，密钥编号更新为所述第三编号。

5.根据权利要求4所述的方法，其特征在于，所述第一服务器利用所述第二密钥对第二待发送业务数据进行加密得到第二加密报文，包括：

所述第一服务器利用所述第二代号对应的加密算法及所述第三编号密钥对第二待发送业务数据进行加密得到第二加密报文；

所述第一服务器向所述第二服务器发送所述第二加密报文，所述第二加密报文包括所述第二代号及所述第三编号，以及加密后的业务数据，使得所述第二服务器利用所述第二加密算法及所述第三编号对应的密钥对所述第二加密报文进行解密。

6.根据权利要求1-2，4-5中任一项所述的方法，其特征在于，所述第一服务器和所述第二服务器均维护第二配置文件，所述第二配置文件用于存储通信双方的所有加密算法及密钥信息；

所述第一服务器将当前使用的密钥由所述第一密钥更换为第二密钥之前，包括：

所述第一服务器向所述第二服务器发送一致性验证请求；

所述第二服务器响应于所述一致性验证请求向所述第一服务器发送所述第二服务器中的第二配置文件对应的第一校验码；

所述第一服务器比较第一校验码与第二校验码是否一致，所述第二校验码是所述第一服务器中的第二配置文件对应的校验码；

所述第一服务器确定所述第一服务器内的第二配置文件与所述第二服务器内的第二配置文件一致后，将当前使用的密钥由第一密钥更换为第二密钥。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一服务器响应于第一密钥配置文件更新命令，重新加载新的第二配置文件，所述新的第二配置文件中除当前正在使用的密钥编号对应的密钥之外的其他全部密钥编号对应的密钥均为更新后的密钥；

所述第二服务器响应于第二密钥配置文件更新命令，重新加载新的第二配置文件，所述新的第二配置文件中除当前正在使用的密钥编号对应的密钥之外的其他全部密钥编号对应的密钥均为更新后的密钥。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一服务器响应于第一密钥更新命令，将所述第一服务器中的第二配置文件中的所述指定加密算法代号对应加密算法中与所述指定密钥编号对应的密钥更新为所述目标密钥，所述第一密钥更新命令包括指定加密算法代号、指定密钥编号及目标密钥；

所述第二服务器获取第二密钥更新命令，所述第二密钥更新命令包括指定加密算法代号、指定密钥编号及目标密钥；

所述第二服务器响应于所述第二密钥更新命令，将所述第二服务器中的第二配置文件中的所述指定加密算法代号对应加密算法中与所述指定密钥编号对应的密钥更新为所述目标密钥。

9.一种服务器间通信密钥升级装置，其特征在于，包括：管理控制台、服务进程、第一配置文件和第二配置文件，所述第一配置文件用于存储当前正在使用的密钥信息，所述密钥信息包括第一编号，所述第二配置文件用于存储多个密钥信息，每个密钥具有一个唯一编号；

所述管理控制台用于向所述服务进程发送密钥变更命令，所述密钥变更命令包括第二编号，所述第二编号为变更后的密钥编号；

所述服务进程响应于所述密钥变更命令，将当前使用的密钥由第一密钥更换为第二密钥，所述第二密钥对应的密钥编号为所述第二编号，以及使用第一加密算法及所述第二编号对应的密钥对待发送业务数据进行加密得到加密报文，所述加密报文包括所述第二编号及加密后的业务数据；

所述服务进程向第二服务器发送所述加密报文，使得所述第二服务器基于所述加密报文中的第二编号对应的密钥解密所述加密报文。

10.一种服务器间通信系统，其特征在于，包括第一服务器和第二服务器，所述第一服务器为发送方服务器，所述第二服务器为接收方服务器；

所述第一服务器利用第一密钥对第一待发送业务数据进行加密得到第一加密报文，第一密钥对应的密钥编号为第一编号，所述第一服务器维护有多个密钥，每个密钥具有一个唯一编号；

所述第一服务器向第二服务器发送所述第一加密报文；

所述第二服务器利用所述第一密钥对所述第一加密报文进行解密；

所述第一服务器将当前使用的密钥由第一密钥更换为第二密钥，所述第二密钥对应的密钥编号为第二编号；

所述第一服务器利用所述第二密钥对第二待发送业务数据进行加密得到第二加密报文，所述第二加密报文包括所述第二编号及加密后的业务数据；

所述第一服务器向所述第二服务器发送所述第二加密报文；

所述第二服务器利用所述第二加密报文中所述第二编号对应的密钥对所述第二加密报文进行解密。

11.一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器、存储器和触摸屏；所述存储器用于存储程序代码；所述处理器用于运行所述程序代码，使得所述电子设备实现如权利要求1至8任一项所述的服务器间通信密钥升级方法。

12.一种计算机可读存储介质，其特征在于，其上存储有指令，当所述指令在服务器上运行时，使得所述服务器执行如权利要求1至8任一项所述的服务器间通信密钥升级方法。