CN110830239A

CN110830239A - 一种密钥更新方法、装置及系统

Info

Publication number: CN110830239A
Application number: CN201810893675.1A
Authority: CN
Inventors: 张锋辉
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2018-08-07
Filing date: 2018-08-07
Publication date: 2020-02-21
Anticipated expiration: 2038-08-07
Also published as: CN110830239B

Abstract

本申请提供一种密钥更新方法、装置及系统。其中所述密钥更新方法，包括：获取第一密钥，其中，所述第一密钥为密钥更新时间之前的当前密钥；在第一时间，获取第二密钥，将先前密钥更新为所述第二密钥，其中，所述第一时间在所述密钥更新时间之前；在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将先前密钥更新为所述第一密钥。采用本申请提供的方法，解决了集群服务器的密钥更新时，由于集群服务器之间非同步更新，从而导致解密失败的问题。

Description

一种密钥更新方法、装置及系统

技术领域

本发明涉及通信技术领域，具体涉及一种密钥更新方法、装置及系统。

背景技术

由于电子商务的交易数量非常庞大，发起交易的客户遍布全球，大型的电子商务服务商普遍采用服务器集群来实现电子商务后台。

服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还能正常运行。集群中的服务器有可能分布在相距较远的不同地理位置。

在电子商务的交易过程中，出于安全的考虑，通常使用HTTPS来实现客户和服务器的通信。在HTTPS中，为了提高用户的体验，使用session tickets机制来快速恢复之前创建的会话。

在session tickets机制中，一个session ticket是一个加密的数据blob，其中包含需要重用的TLS连接信息，如cipher_suite、master_secret等。session ticket使用session ticket key加密。服务器端持有session ticket key，在初始握手中服务器发送一个session ticket到客户端，存储到客户端本地，当重用会话时，客户端发送sessionticket到服务器，服务器解密然后重用会话。

在多数开源proxy软件中都能支持session ticket key的配置，例如nginx中使用ssl_session_ticket_key file指令来配置用于加密或解密TLS session ticket的密钥。现有技术方案中，一种是将多台proxy主机静态配置为相同的session ticket key file，由于没有定期自动更换session ticket key的机制，会导致系统的安全性存在隐患。另一种是定期更换session ticket key，在集群服务器收到更新的session ticket key之后，立即将所述更新的session ticket key作为当前密钥使用。采用这种方案，在集群服务器之间的时间不一致的情况下，会导致session ticket key解密失败。

发明内容

本申请提供一种密钥更新方法、装置及系统，以解决集群服务器的密钥更新时，由于集群服务器之间非同步更新，从而导致解密失败的问题。

本申请提供的密钥更新方法，包括：

获取第一密钥，其中，所述第一密钥为密钥更新时间之前的当前密钥；

在第一时间，获取第二密钥，将先前密钥更新为所述第二密钥，其中，所述第一时间在所述密钥更新时间之前；

在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将先前密钥更新为所述第一密钥。

可选的，所述在第一时间，获取第二密钥，包括：

接收密钥管理控制平台发送的携带有所述第二密钥的密钥更新指令；

对所述密钥更新指令进行解析，获取所述第二密钥。

可选的，所述在第一时间，获取第二密钥，包括：

从当前计算设备的密钥缓存区中直接读取所述第二密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第二密钥。

可选的，还包括：从所述第一时间开始，直至所述密钥更新时间结束，如果使用所述第一密钥对待解密信息解密失败，则使用所述第二密钥对所述待解密信息进行解密。

可选的，还包括：从所述密钥更新时间开始，如果使用所述第二密钥对待解密信息解密失败，则使用所述第一密钥对所述待解密信息进行解密。

可选的，还包括：

获取密钥管理控制平台发送的携带有所述第一时间的密钥更新控制指令；

对所述密钥更新控制指令进行解析，获取所述第一时间数据。

可选的，还包括：

获取包含所述第一时间的配置文件；

对所述配置文件进行解析，获取所述第一时间。

可选的，所述密钥更新时间和所述第一时间均为当前计算设备的本地时间。

可选的，所述密钥更新时间与所述第一时间的时间差不小于计算设备集群中所有计算设备的本地时间之间的最大时间差。

可选的，所述方法还包括：

向密钥管理控制平台发出获取初始密钥的请求；

获取所述密钥管理控制平台返回的第三密钥和所述第一密钥；

所述第三密钥为获取所述第二密钥之前的先前密钥。

可选的，所述方法还包括：所述第一密钥和第三密钥为初始密钥，所述第三密钥为获取所述第二密钥之前的先前密钥；

所述方法还包括：

从当前计算设备的密钥缓存区中直接读取第三密钥和所述第一密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第三密钥和所述第一密钥；

所述第三密钥为获取所述第二密钥之前的先前密钥。

相应的，本申请还提供一种密钥更新装置，包括：

第一密钥获取单元，用于获取第一密钥，其中，所述第一密钥为密钥更新时间之前的当前密钥；

第二密钥获取单元，用于在第一时间，获取第二密钥，将先前密钥更新为所述第二密钥，其中，所述第一时间在所述密钥更新时间之前；

密钥更新单元，用于在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将先前密钥更新为所述第一密钥。

可选的，所述第二密钥获取单元，具体用于接收密钥管理控制平台发送的携带有所述第二密钥的密钥更新指令；对所述密钥更新指令进行解析，获取所述第二密钥。

可选的，所述第二密钥获取单元，具体用于从当前计算设备的密钥缓存区中直接读取所述第二密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第二密钥。

可选的，还包括：解密失败处理单元，具体用于从所述第一时间开始，直至所述密钥更新时间结束，如果使用所述第一密钥对待解密信息解密失败，则使用所述第二密钥对所述待解密信息进行解密。

可选的，还包括：解密失败处理单元，具体用于：从所述密钥更新时间开始，如果使用所述第二密钥对待解密信息解密失败，则使用所述第一密钥对所述待解密信息进行解密。

可选的，还包括：第一时间数据获取单元，具体用于获取密钥管理控制平台发送的携带有所述第一时间的密钥更新控制指令；对所述密钥更新控制指令进行解析，获取所述第一时间。

可选的，还包括：第一时间数据获取单元，具体用于获取包含所述第一时间的配置文件；对所述配置文件进行解析，获取所述第一时间。

可选的，所述装置还包括初始密钥获取单元，具体用于向密钥管理控制平台发出获取初始密钥的请求；获取所述密钥管理控制平台返回的第三密钥和所述第一密钥；所述第三密钥为获取所述第二密钥之前的先前密钥。

可选的，所述装置还包括：初始密钥获取单元，具体用于从当前计算设备的密钥缓存区中直接读取第三密钥和所述第一密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第一密钥和所述第三密钥；

所述第三密钥为获取所述第二密钥之前的先前密钥。

本申请还提供一种计算设备集群系统，包括至少两个计算设备，每个计算设备用于：

在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将先前密钥更新为所述第一密钥；

其中，所述计算设备的本地时间之间存在时间差，所述密钥更新时间与所述第一时间的时间差不小于所述至少两个计算设备的本地时间之间的最大时间差。

可选的，在所述至少两个计算设备中，至少有一个计算设备为所述计算设备集群系统中的proxy主机。

可选的，所述proxy主机运行nginx系统。

可选的，所述第一密钥和所述第二密钥均为用于对TLS session ticket进行解密的密钥。

本申请还提供一种电子设备，其特征在于，所述电子设备包括：

处理器；

存储器，用于存储程序，所述程序在被所述处理器读取执行时，执行如下操作：

本申请还提供一种计算机可读取存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时，实现以下步骤：

与现有技术相比，本申请具有如下优点：

本申请提供的密钥更新方法，包括：获取第一密钥，其中，所述第一密钥为密钥更新时间之前的当前密钥；在第一时间，获取第二密钥，将先前密钥更新为所述第二密钥，其中，所述第一时间在所述密钥更新时间之前；在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将先前密钥更新为所述第一密钥。采用本申请提供的方法，在所述密钥更新时间之前的第一时间，获取了第二密钥，将先前密钥更新为所述第二密钥，此时的当前密钥仍为所述第一密钥，这样集群服务器中本地时间比较晚的服务器在接收到本地时间比较早的用所述第二密钥加密的数据时，能够使用本地时间比较晚的服务器中作为先前密钥的第二密钥进行解密，从而解决了集群服务器的密钥更新时，由于集群服务器之间非同步更新，从而导致解密失败的问题。

附图说明

图1是本申请一种密钥更新方法的实施例的流程图。

图2是本申请一种密钥更新方法涉及的session ticket机制的流程示意图。

图3是本申请一种密钥更新方法涉及的密钥管理控制平台发送密钥更新指令的示意图。

图4是本申请一种密钥更新装置的实施例的流程图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

本申请第一实施例提供一种密钥更新方法。请参看图1，该图为本申请第一实施例的流程图。以下结合图1对本申请第一实施例进行详细说明。所述方法包括如下步骤：

步骤S101：获取第一密钥，其中，所述第一密钥为密钥更新时间之前的当前密钥。

本步骤用于获取第一密钥，其中，所述第一密钥为密钥更新时间之前的当前密钥。

本步骤可以用于计算设备在刚刚启动后，计算设备尚未获取密钥对中的当前密钥和先前密钥时，所述计算设备可以通过向密钥管理平台发送获取初始密钥等方式，获取用于作为当前密钥的第一密钥。

本步骤也可以用于在不小于第二个密钥更新周期，获取第一密钥，此时获取的第一密钥即为在所述不小于第二个密钥更新周期对应的密钥更新时间之前的正在使用的当前密钥，获取的第一密钥继续作为当前密钥使用。

现有技术方案中，使用两个密钥对数据进行操作。这两个密钥分别称为当前密钥和先前密钥。例如，在nginx系统中，使用下面的ssl_session_ticket_key命令分别对将第一密钥key1设置为当前密钥，将第三密钥key3设置为先前密钥。

ssl_session_ticket_key key1；

ssl_session_ticket_key key3；

在所述配置命令完成之后，当前密钥key1可以针对session ticket执行加解密操作，而作为先前密钥的第三密钥key3只可以针对session ticket执行解密操作。使用这种双密钥机制可以保证在密钥更新之后，还可以对先前密钥加密的数据进行解密。

session ticket机制是https的一种会话复用机制。新的会话后，服务器通过一个自己知道的密钥ticket key将本次的会话状态加密后生成一个ticket，然后发送给客户端，客户端保存着这个ticket。下次客户端再和服务器建立ssl连接的时候，将此ticket发送给服务器，由于这个ticket只有服务器能够解开，而且ticket key不被外界所知，安全性有一定的保障。服务器解开这个ticket后，拿出里面的会话状态(包括cipher_suite、master_secret等)，然后就开始用这个会话密钥进行加密通信。这种方式达到了会话复用的目的，且将所有的存储压力都转移到客户端，具有可扩展性。现阶段所有主流的浏览器都首先支持sessionticket的复用方式。图2是session ticket机制的流程示意图。

下面对于现有技术中采用这种双密钥机制的集群中的服务器的密钥更新方法进行详细说明。

集群中的每个服务器初始状态下都持有两个密钥，分别为第一密钥key1和第三密钥key3。其中所述第一密钥key1作为当前密钥，用于对当前时间周期的session ticket进行加解密；第三密钥key3作为先前密钥，用于对先前时间周期的session ticket进行解密。所述第一密钥key1可以执行加解密操作，所述第三密钥key3只能执行解密操作。

在约定的密钥更新时间，集群中的每个服务器获得更新的第二密钥key2。在获得所述第二密钥key2之后，执行下述指令：

ssl_session_ticket_key key2；

ssl_session_ticket_key key1；

执行上述指令后，集群中的每个服务器都持有两个密钥，分别为第二密钥key2和第一密钥key1。其中所述第二密钥key2作为当前密钥，用于对当前时间周期的sessionticket进行加解密；所述第一密钥key1作为先前时间周期密钥，用于对先前时间周期的session ticket进行解密。这时，所述第二密钥key2能够执行加解密操作，所述第一密钥key1只能执行解密操作。

如上所述的这种密钥的更新处理方法在集群中的各服务器之间的时间保持精准同步的情况下是没有问题的。但是，由于集群中的服务器可能分布的物理距离比较远，这样就会导致集群中服务器之间的时间很难保持一致。集群服务器之间的时间不一致就会导致session ticket不能够被成功解密。

例如，在实际时间UTC 12:00pm，集群中的服务器A的本地时间是UTC 12:05pm，而集群中的服务器B的本地时间是UTC 11:55am。如果集群中的服务器约定的密钥更新时间为每天的本地时间UTC 12:00pm，服务器A在本地时间UTC 12:00pm(实际时间为UTC 11:55am)获得更新的第二密钥key2，将所述第二密钥key2作为自己的当前密钥，将所述第一密钥key1作为自己的先前密钥。服务器A在本地时间UTC 12:01pm时间(实际时间为UTC 11:56am)使用第二密钥key2对session ticket进行加密，由于服务器B的本地时间比服务器A的本地时间晚10分钟，服务器B在本地时间UTC 11:51am(实际的时间为UTC 11:56am)收到这个使用第二密钥key2加密的session ticket。对服务器B而言，此时约定的密钥更新时间即本地时间UTC 12:00pm(实际时间为UTC 12:05pm)还没有到，因此服务器B并没有获得更新的密钥第二密钥key2，此时服务器B使用持有的当前密钥第一密钥key1，或者持有的先前密钥第三密钥key3均不能成功的解密这个使用第二密钥key2加密的session ticket。

从上面的失败过程可以看出，导致所述使用第二密钥key2加密的session ticket不能被成功解密的原因在于集群中的服务器之间的时间不一致，集群中有的服务器使用了更新的第二密钥key2，而没有获取第二密钥key2的服务器无法针对第二密钥key2加密的数据进行处理。

步骤S102：在第一时间，获取第二密钥，将先前密钥更新为所述第二密钥，其中，所述第一时间在所述密钥更新时间之前。

本步骤用来在密钥更新时间之前的第一时间，获取用于在所述密钥更新时间之后作为当前密钥的第二密钥，并将所述第二密钥设置为先前密钥。

所述密钥更新时间和所述第一时间均为当前计算设备的本地时间。所述计算设备的本地时间是指计算设备自身计时系统的UTC时间。

所述密钥更新时间与所述第一时间的时间差不小于计算设备集群中所有计算设备的本地时间之间的最大时间差。

所述计算设备的本地时间是指计算设备自身计时系统的UTC时间。所述计算设备集群中所有计算设备的本地时间之间的最大时间差是指集群中时间最早的计算设备与集群中时间最晚的计算设备之间时间差值。例如现在的实际时间为UTC9:00am，集群中时间最早的计算设备时间为UTC9:10am，集群中时间最晚的计算设备时间为UTC8:45am，则所述计算设备集群中所有计算设备的本地时间之间的最大时间差＝UTC9:10am-UTC8:45am＝25分钟。

所述获取第二密钥可以采用多种方法来获取，下面对两种获取方法进行详细说明。

所述获取第二密钥，包括：

对所述密钥更新指令进行解析，获取所述第二密钥。

在集群服务器中，可以设置专门的密钥管理控制平台，针对集群中的每个服务器的密钥进行管理。

密钥管理控制平台产生密钥更新指令，将所述密钥更新指令发送给集群中的每个服务器。所述密钥更新指令包含了所述第二密钥。服务器接收由密钥管理控制平台发送的密钥更新指令之后，对所述密钥更新指令进行解析获取所述第二密钥。当所述服务器为proxy服务器时，图3提供了密钥管理控制平台发送密钥更新指令的示意图。

所述密钥更新指令可以由所述密钥管理控制平台定期发送。例如可以在所述密钥管理控制平台设置每天的UTC12:00发送所述密钥更新指令。

所述获取第二密钥，包括：

用于集群中密钥管理服务系统也可以采用分布式部署，这样集群在几个不同的地理位置可以部署不同的集群中密钥管理服务系统。所有的密钥管理服务系统都包含了存放密钥的密钥缓冲区以及数据同步单元。

密钥管理服务系统提供密钥缓存区机制，将密钥产生器产生的密钥共享存储在密钥缓存区中，业务应用系统处理时可以直接从密钥缓存区中获取指定的密钥，完成业务应用系统密码运算功能。密钥缓存区大小，根据实际应用情况手动设定。密钥缓存区可避免业务应用系统每次处理都从密钥产生器中获取指定密钥，缩短密钥获取时间。

当发送端密钥缓存区密钥对象发生变化时(新增、更新、销毁等)，具体实施方法为：通过发送端的数据同步服务，序列化发生变化后的密钥对象；发送端通过JAVA RMI远程方法调用，将序列化后的密钥对象发送到接收端的数据同步服务；接收端的数据同步服务，通过反序列化恢复成为密钥对象；接收端的数据同步服务从密钥缓存区中，获取现有密钥对象，与反序列化后密钥对象比较，将变化后的密钥对象更新到接收端的密钥缓存区；接收端把更新结果返回到发送端，完成缓存区中密钥实时同步管理。

集群服务器可以从距离自己最近的所述密钥缓存中直接读取所述第二密钥。由于密钥缓存区可以位于当前计算设备，也可以位于其他计算设备，因此可以从当前计算设备的密钥缓存区中直接读取所述第二密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第二密钥。

所述第一时间可以通过如下步骤获取：

获取密钥管理控制平台发送的携带有第一时间数据的密钥更新控制指令；

所述第一时间可以从密钥更新控制指令中获取。密钥管理控制平台在构建密钥更新控制指令时，将第一时间也包含在内，这样集群服务器收到所述密钥更新控制指令，对所述密钥更新控制指令进行解析获取所述第一时间。当然密钥管理控制平台也可以使用其他的指令向集群服务器发送包含所述第一时间的信息。

所述第一时间还可以通过如下步骤获取：

获取包含所述第一时间的配置文件；

对所述配置文件进行解析，获取所述第一时间。

在nginx等系统中，第一时间也可以保存在配置文件中。集群服务器读取包含所述提前的时间的配置文件，根据所述配置文件，获取所述第一时间。

在所述获取所述第三密钥之后，所述第三密钥只能在内存中保存。通过在所述获取所述第三密钥之后，所述第三密钥只能在内存中保存的方式，降低了密钥泄露的风险。针对第一密钥和第二密钥也可以采用这种方法。

所述密钥更新时间和所述第一时间均为当前计算设备的本地时间。

当前计算设备的本地时间是指当前计算设备的计时系统的UTC时间。

所述方法还包括：

向密钥管理控制平台发出获取初始密钥的请求；

所述第三密钥为获取所述第二密钥之前的先前密钥。

获取所述第二密钥之前的先前密钥是第三密钥，所述初始密钥是指服务器启动时的当前密钥或者先前密钥。

服务器在启动后，向密钥管理控制平台发出获取初始密钥的请求；密钥管理控制平台根据收到的所述获取初始密钥的请求，向所述服务器返回包含所述作为当前密钥的第一密钥和作为先前密钥的第三密钥。所述第一密钥和第三密钥是初始密钥。

所述第一密钥和第三密钥为初始密钥，所述第三密钥为获取所述第二密钥之前的先前密钥；

所述方法还包括：从当前计算设备的密钥缓存区中直接读取所述第一密钥和所述第三密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第一密钥和所述第三密钥。

集群服务器可以从距离自己最近的接收端的所述密钥缓存中直接获取所述第一密钥和所述第三密钥。具体可以从当前计算设备的密钥缓存区中直接读取所述第一密钥和所述第三密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第一密钥和所述第三密钥。

在nginx系统中，执行下面的两个指令就可以实现将所述第二密钥key2作为先前密钥，将所述第一密钥key1作为当前密钥。

ssl_session_ticket_key key1；

ssl_session_ticket_keykey2；

在执行完上述指令之后，第一密钥key1的作用保持不变，继续对数据执行加解密。第二密钥key2针对数据执行解密操作。

从所述第一时间开始，直至所述密钥更新时间结束，如果使用所述第一密钥对待解密信息解密失败，则使用所述第二密钥对所述待解密信息进行解密。

这样，尽管集群中的两个服务器A和服务器B的时间不一致，服务器A和服务器B对于session ticket都能够成功的处理。下面对于所述处理的过程进行详细说明。

在实际的当前时间UTC 12:00pm，集群中的服务器A的本地时间是UTC 12:05pm，而集群中的服务器B的本地时间是UTC 11:55am。如果集群中的服务器约定的密钥更新时间为每天的本地时间UTC 12:00pm。服务器A和服务器B提前30分钟获取用来更新当前密钥第一密钥key1的第二密钥key2。

服务器A在本地时间UTC 11:30am(实际时间为UTC 11:25am)获取第二密钥key2，并将所述第二密钥key2作为先前密钥，将所述第一密钥key1作为当前密钥。服务器B在本地时间UTC 11:30am(实际时间为UTC 11:35am)获取第二密钥key2，并将所述第二密钥key2作为先前密钥，而将所述第一密钥key1作为当前密钥。

服务器A在本地时间UTC 12:01pm(实际时间为UTC 11:56am)使用第三密钥key3对session ticket进行加密，服务器B此时本地为UTC 11:51am(实际时间为UTC 11:56am)。由于服务器B在本地时间UTC 11:30am(实际时间为UTC 11:35am)已经将第二密钥key2作为先前密钥，将第一密钥key1作为当前密钥，因此使用第二密钥key2可以成功解密服务器A在本地时间UTC 12:01pm(实际时间为UTC 11:56am)发出的这个使用第二密钥key2加密的session ticket。

本申请提出在密钥更新时间之前的第一时间，获取用于在所述密钥更新时间之后作为当前密钥的第二密钥，并将所述第二密钥设置为先前密钥，这样就解决了集群中服务器之间的时间不一致而导致的后获取第二密钥key2的服务器针对先获取第二密钥key2的服务器加密的数据不能够成功解密的问题。

步骤S103：在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将先前密钥更新为所述第一密钥。

本步骤用于在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将先前密钥更新为所述第一密钥。

例如在nginx系统中，执行下面的两个指令就可以实现当前密钥更新为所述第二密钥key2，将所述先前密钥更新为第一密钥key1。

ssl_session_ticket_key key2；

ssl_session_ticket_key key1；

在执行完上述指令之后，第一密钥key1对数据执行解密操作。第二密钥key2针对数据执行加解密操作。

从所述密钥更新时间开始，如果使用所述第二密钥对待解密信息解密失败，则使用所述第一密钥对所述待解密信息进行解密。

下面通过一个实例对本步骤进行详细说明。

在实际时间UTC 12:00pm，集群中的服务器A的本地时间是UTC 12:05pm，而集群中的服务器B的本地时间是UTC 11:55am。如果集群中的服务器约定的密钥更新时间为每天的本地时间UTC 12:00pm。服务器A和服务器B提前30分钟获取用来更新当前密钥第一密钥key1的第二密钥key2。

当集群中的服务器的密钥更新时间，即计算设备的本地时间UTC 12:00pm到达后，服务器A在本地时间UTC 12:00pm(实际时间为UTC 11:55am)，将第二密钥key2作为当前密钥，而将第一密钥key1作为先前密钥。服务器B在本地时间UTC 12:00pm(实际时间为UTC12:05pm)将第二密钥key2作为当前密钥，而将第一密钥key1作为先前密钥。

在上述的实施例中，提供了一种密钥更新方法，与之相对应的，本申请还提供一种密钥更新装置。请参看图4，其为本申请的一种密钥更新装置实施例的流程图。由于本实施例，即第二实施例，基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种密钥更新装置，包括：

第一密钥获取单元401，用于获取第一密钥，其中，所述第一密钥为密钥更新时间之前的当前密钥；

第一密钥获取单元402，用于在第一时间，获取第二密钥，将先前密钥更新为所述第二密钥，其中，所述第一时间在所述密钥更新时间之前；

密钥更新单元403，在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将先前密钥更新为所述第一密钥。

可选的，所述密钥更新装置还包括：解密失败处理单元，具体用于从所述第一时间开始，直至所述密钥更新时间结束，如果使用所述第一密钥对待解密信息解密失败，则使用所述第二密钥对所述待解密信息进行解密。

可选的，所述密钥更新装置还包括：解密失败处理单元，具体用于：从所述密钥更新时间开始，如果使用所述第二密钥对待解密信息解密失败，则使用所述第一密钥对所述待解密信息进行解密。

可选的，所述密钥更新装置还包括：第一时间数据获取单元，具体用于获取密钥管理控制平台发送的携带有第一时间数据的密钥更新控制指令；对所述密钥更新控制指令进行解析，获取所述第一时间数据。

可选的，所述密钥更新装置还包括：第一时间数据获取单元，具体用于获取包含所述第一时间数据的配置文件；对所述配置文件进行解析，获取所述第一时间数据。

可选的，所述密钥更新装置还包括初始密钥获取单元，具体用于向密钥管理控制平台发出获取初始密钥的请求；获取所述密钥管理控制平台返回的第三密钥和所述第一密钥；

所述第三密钥为获取所述第二密钥之前的先前密钥。

可选的，所述第一密钥和第三密钥为初始密钥，所述第三密钥为获取所述第二密钥之前的先前密钥；

所述密钥更新装置还包括初始密钥获取单元，具体用于从当前计算设备的密钥缓存区中直接读取所述第一密钥和所述第三密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第一密钥和所述第三密钥。

本申请第三实施例提供一种计算设备集群系统，该计算设备集群系统用于实现上述第一实施例提供的方法。

所述计算设备集群系统，包括至少两个计算设备，每个计算设备用于：

可选的，所述proxy主机运行nginx系统。

本申请第四实施例提供一种电子设备，所述电子设备包括：

处理器；

本申请第五实施例提供一种计算机可读取存储介质，其上存储有计算机程序，所述程序被处理器执行时，实现以下步骤：

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims

1.一种密钥更新方法，其特征在于，包括：

在所述密钥更新时间，将所述当前密钥更新为所述第二密钥，将所述先前密钥更新为所述第一密钥。

2.根据权利要求1所述的密钥更新方法，其特征在于，所述获取第二密钥，包括：

对所述密钥更新指令进行解析，获取所述第二密钥。

3.根据权利要求1所述的密钥更新方法，其特征在于，所述获取第二密钥，包括：

4.根据权利要求1所述的密钥更新方法，其特征在于，还包括：从所述第一时间开始，直至所述密钥更新时间结束，如果使用所述第一密钥对待解密信息解密失败，则使用所述第二密钥对所述待解密信息进行解密。

5.根据权利要求1所述的密钥更新方法，其特征在于，还包括：从所述密钥更新时间开始，如果使用所述第二密钥对待解密信息解密失败，则使用所述第一密钥对所述待解密信息进行解密。

6.根据权利要求1所述的密钥更新方法，其特征在于，还包括：

对所述密钥更新控制指令进行解析，获取所述第一时间。

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

获取包含所述第一时间的配置文件；

对所述配置文件进行解析，获取所述第一时间。

8.根据权利要求1所述的密钥更新方法，其特征在于，所述密钥更新时间和所述第一时间均为当前计算设备的本地时间。

9.根据权利要求1、6或7所述的密钥更新方法，其特征在于，所述密钥更新时间与所述第一时间的时间差不小于计算设备集群中所有计算设备的本地时间之间的最大时间差。

10.根据权利要求1所述的密钥更新方法，其特征在于，还包括：

向密钥管理控制平台发出获取初始密钥的请求；

所述第三密钥为获取所述第二密钥之前的先前密钥。

11.根据权利要求1所述的密钥更新方法，其特征在于，还包括：从当前计算设备的密钥缓存区中直接读取第三密钥和所述第一密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第三密钥和所述第一密钥；

所述第三密钥为获取所述第二密钥之前的先前密钥。

12.一种密钥更新装置，其特征在于，包括：

13.根据权利要求12所述的密钥更新装置，其特征在于，所述第二密钥获取单元，具体用于接收密钥管理控制平台发送的携带有所述第二密钥的密钥更新指令；对所述密钥更新指令进行解析，获取所述第二密钥。

14.根据权利要求12所述的密钥更新装置，其特征在于，所述第二密钥获取单元，具体用于从当前计算设备的密钥缓存区中直接读取所述第二密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第二密钥。

15.根据权利要求12所述的密钥更新装置，其特征在于，还包括：解密失败处理单元，具体用于从所述第一时间开始，直至所述密钥更新时间结束，如果使用所述第一密钥对待解密信息解密失败，则使用所述第二密钥对所述待解密信息进行解密。

16.根据权利要求12所述的密钥更新装置，其特征在于，还包括：解密失败处理单元，具体用于：从所述密钥更新时间开始，如果使用所述第二密钥对待解密信息解密失败，则使用所述第一密钥对所述待解密信息进行解密。

17.根据权利要求12所述的密钥更新装置，其特征在于，还包括：第一时间数据获取单元，具体用于获取密钥管理控制平台发送的携带有所述第一时间的密钥更新控制指令；对所述密钥更新控制指令进行解析，获取所述第一时间。

18.根据权利要求12所述的密钥更新装置，其特征在于，还包括：第一时间数据获取单元，具体用于获取包含所述第一时间的配置文件；对所述配置文件进行解析，获取所述第一时间。

19.根据权利要求12所述的密钥更新装置，其特征在于，所述密钥更新时间和所述第一时间均为当前计算设备的本地时间。

20.根据权利要求12、17或18所述的密钥更新装置，其特征在于，所述密钥更新时间与所述第一时间的时间差不小于计算设备集群中所有计算设备的本地时间之间的最大时间差。

21.根据权利要求12所述的密钥更新装置，其特征在于，还包括初始密钥获取单元，具体用于向密钥管理控制平台发出获取初始密钥的请求；获取所述密钥管理控制平台返回的第三密钥和所述第一密钥；

所述第三密钥为获取所述第二密钥之前的先前密钥。

22.根据权利要求12所述的密钥更新装置，其特征在于，还包括初始密钥获取单元，具体用于从当前计算设备的密钥缓存区中直接读取第三密钥和所述第一密钥，或者，从独立于当前计算设备的密钥缓存区中获取所述第三密钥和所述第一密钥和所述第三密钥；

所述第三密钥为获取所述第二密钥之前的先前密钥。

23.一种计算设备集群系统，其特征在于，包括至少两个计算设备，每个计算设备用于：

24.根据权利要求23所述的计算设备集群系统，其特征在于，在所述至少两个计算设备中，至少有一个计算设备为所述计算设备集群系统中的proxy主机。

25.根据权利要求24所述的计算设备集群系统，其特征在于，所述proxy主机运行nginx系统。

26.根据权利要求23所述的计算设备集群系统，其特征在于，所述第一密钥和所述第二密钥均为用于对TLS session ticket进行解密的密钥。

27.一种电子设备，其特征在于，所述电子设备包括：

处理器；

28.一种计算机可读取存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时，实现以下步骤：