CN102130891B - 一种基于tcp的密钥协调方法和系统 - Google Patents

Abstract

本发明公开了一种基于TCP的密钥协调方法和系统，其中，所述方法包括：发送方和接收方进行密钥协调过程中，发送方要求接收方使用新的密钥时，若接收方当前无法使用所述新的密钥，则接收方通过在传输控制协议(TCP)报文的可选字段中携带控制信息发送给发送方，将自身密钥使用情况告知发送方。本发明通过在TCP报文的可选字段中携带控制信息，可以有效避免在密钥更新时由于一方的密钥没有准备好而出现的异常的情况。本发明实现简单，便于实际应用。

Description

一种基于TCP的密钥协调方法和系统

技术领域

本发明涉及数据通信安全领域，尤其涉及一种基于TCP（Transfer ControlProtocol，传输控制协议）的密钥协调方法和系统。

背景技术

在RFC2385中，出现了基于TCP可选字段的认证技术，在这里面，主要是利用带有密钥的MD5的认证思想，对于通信的双方，都拥有静态的配置好的密钥，然后在TCP的可选字段中拿出18个字节（Byte）的空间，具体见图1，其中第一个为类型（Kind）字段，第二个为长度（Length）字段，后面的16个Byte都是MD5的认证字段。认证的内容按顺序如下：

1、TCP伪头部（IP源地址和目的地址，协议号，报文长度）

2、TCP的头部（除去可选字段和校验和）

3、TCP的数据负载

4、密钥

然后把上面的4个内容按顺序作为MD5算法的输入，算法的128位的输出填充到认证字段的16个Byte中去。接收方在收到这个报文后，也按照同样的顺序用同样的共享的密钥进行MD5运算，如果得出的认证值和接收到的值相同，则认为这个报文来自于合法的对等方并且此报文在通信过程中没有被修改。如果得出的认证值和接收到的值不相等，则认为此报文是敌手伪造或者在传输过程中被篡改并丢弃此报文。

然而，这个用带密钥的MD5构造MAC码的方法有如下的缺陷：

1、此方法只允许使用MD5算法，而在2005年，山东大学的王小云教授在国际密码学大会上提出，用她发明的模差分和消息修改的方法，可以在2^39次方的复杂度内找到一组碰撞，这表明，在现有的计算能力的条件下，MD5已经不再安全，而只允许MD5作为可用的算法，显然不合理。

2、TCP-MD5密钥的更新非常困难，有可能会丢失报文或者需要尝试所有的在本地数据库中可能的密钥来验证报文中的认证码字段。

3、不能抗重放攻击。

在这种情况下，有人提出一种新的利用可选字段的方法，主要的改进如下：

1、哈希（Hash）算法更加强壮，使用了SHA-1来代替MD5。

2、算法的敏捷性提高，提供了多种MAC生成方法来提供认证。

3、提供一个简单的密钥协调方法。

4、使用了序列号扩展来抵抗重放攻击。

在提出的这个简单的密钥协调方案中，发送的报文中的认证可选字段变成了图2的形式，即：有两个密钥的标识（ID），一个为KeyID，另一个为RNextKeyID，其中的KeyID作为现在通信所用的密钥的ID，而RNextKeyID作为要更新的密钥的ID。当有一方准备要求更换密钥的时候，可以在RNextKeyID里面填上准备好的密钥的ID，然后接收方收到这个报文的时候查RNextKeyID中的内容，匹配这个密钥和自己的数据库中的密钥，如果有这个密钥并且配置完全的话，就用这个协调好的密钥进行下一次的交换。

这里有一个问题，如果接收方在收到RNextKeyID后发现，在自己的数据库中并没有找到匹配的密钥，或者这个密钥没有配置好，那么通信就造成了异常，出现了一方多次要求更换密钥但是一方一直使用旧密钥的情况。

发明内容

本发明要解决的技术问题就是提出一种基于TCP的密钥协调方法，避免密钥协调过程中出现上述通信异常。

为了解决上述技术问题，本发明提供一种基于TCP的密钥协调方法，包括：

发送方和接收方进行密钥协调过程中，发送方要求接收方使用新的密钥时，若接收方当前无法使用所述新的密钥，则接收方通过在传输控制协议（TCP）报文的可选字段中携带控制信息发送给发送方，将自身密钥使用情况告知发送方。

进一步地，上述方法还可具有以下特点：

所述接收方当前无法使用所述新的密钥具体是指下述两种情况之一：

（1）接收方不同意使用所述新的密钥；

（2）接收方同意使用所述新的密钥，但是当前没有配置好所述新的密钥。

进一步地，上述方法还可具有以下特点：

所述接收方不同意使用所述新的密钥的情况包括：发送方没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏。

进一步地，上述方法还可具有以下特点：

若接收方通过TCP报文的可选字段中携带控制信息告知所述发送方，接收方不同意使用所述新的密钥，则所述发送方判断自身维护的第一计数器是否超限；

若所述第一计数器未超限，则发送方设置所述第一计数器的值加1，重新选择新的密钥并告知接收方；

若所述第一计数器超限，则发送方初始化第一计数器，通过在TCP报文的可选字段中携带控制信息发送给接收方，告知发送方密钥选择权交换，由发送方重新选择新的密钥。

进一步地，上述方法还可具有以下特点：

接收方同意使用所述新的密钥，但是当前没有配置好所述新的密钥的具体过程包括：

若接收方通过TCP报文的可选字段中携带控制信息告知所述发送方，接收方同意使用所述新的密钥，但是当前没有配置好所述新的密钥，则所述发送方判断自身维护的第二计数器是否超限；

若所述第二计数器未超限，则所述发送方设置所述第二计数器的值加1，在下一次与接收方的会话中重新要求所述接收方使用所述新的密钥；

若所述第二计数器超限，则发送方初始化第二计数器，并判断所述第一计数器是否超限；若所述第一计数器未超限，则发送方设置所述第一计数器的值加1，重新选择新的密钥并告知接收方；若所述第一计数器超限，则发送方初始化第一计数器，通过在TCP报文的可选字段中携带控制信息发送给接收方，告知发送方密钥选择权交换，由发送方重新选择新的密钥。

进一步地，上述方法还可具有以下特点：

所述TCP报文的可选字段中携带控制信息具体是指：TCP报文的新的密钥标识（RNextKeyID）字段中携带控制信息，或者，TCP报文的控制字段中携带控制信息。

进一步地，上述方法还可具有以下特点：

所述TCP报文的RNextKeyID字段中携带控制信息，具体是指：RNextKeyID字段中的0XF0～0XFF用作控制信息，其中：

（1）若RNextKeyID字段为0Xff，则表示没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏；

（2）若RNextKeyID字段为0Xfe，则表示同意使用所述新的密钥，但是没有配置好；

（3）若RNextKeyID字段为0Xfd，则表示密钥选择权交换。

进一步地，上述方法还可具有以下特点：

所述TCP报文的控制字段中携带控制信息，具体是指：RNextKeyID字段后的1字节控制字段用于携带控制信息，其中：

（1）若控制字段为0Xff，则表示没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏；

（2）若控制字段为0Xfe，则表示同意使用所述新的密钥，但是没有配置好；

（3）若控制字段为0Xfd，则表示密钥选择权交换。

为了解决上述技术问题，本发明提供一种基于TCP的密钥协调系统，包括发送方和接收方，

所述发送方用于和接收方进行密钥协调过程中，要求接收方使用新的密钥；

所述接收方用于若当前无法使用所述新的密钥，则通过在TCP报文的可选字段中携带控制信息发送给发送方，将自身密钥使用情况告知发送方。

进一步地，上述系统还可具有以下特点：

所述TCP报文的可选字段中携带控制信息具体是指：TCP报文的RNextKeyID字段中携带控制信息，或者，TCP报文的控制字段中携带控制信息。

本发明通过在TCP报文的可选字段中携带控制信息，可以有效避免在密钥更新时由于一方的密钥没有准备好而出现的异常的情况。本发明实现简单，便于实际应用。

附图说明

图1是TCP-MD5的可选字段格式示意图；

图2是第二种可选字段格式示意图；

图3是本发明实施例的异常处理状态转移图；

图4是本发明应用示例的情况1的示意图；

图5是本发明应用示例的情况2的示意图；

图6是本发明应用示例的情况3的示意图。

具体实施方式

本发明的基本思想在于利用TCP报文的可选字段来处理密钥更新过程中由于一方的密钥没有准备好而出现的异常的情况。

具体地，发送方和接收方进行密钥协调过程中，发送方要求接收方使用新的密钥时，若接收方当前无法使用所述新的密钥，则接收方通过在TCP报文的可选字段中携带控制信息发送给发送方，将自身密钥使用情况告知发送方。

其中，所述接收方当前无法使用所述新的密钥具体是指下述两种情况之一：

（1）接收方不同意使用所述新的密钥（包括发送方没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏）；

（2）接收方同意使用所述新的密钥，但是当前没有配置好所述新的密钥。

针对TCP报文的可选字段中携带控制信息，本发明提出两种方式：

方式一：

TCP报文的RNextKeyID字段中携带控制信息：

在RNextKeyID字段保留出0XF0～0XFF这段空间用来作为密钥协商的控制字段。在这段空间中最多可以定义16种保留的控制信息。目前启用的三个保留信息为：

（A）RNextKeyID字段为0Xff，表示接收方不同意使用所述新的密钥（没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏）；

（B）RNextKeyID字段为0Xfe，表示同意使用所述新的密钥，但是没有配置好；

（C）RNextKeyID字段为0Xfd，表示密钥选择权交换。

其中（A）和（B）保留的控制信息用于接收方的回应报文中，而（C）保留的控制信息是用于发送方的报文中。

方式二

TCP报文的控制字段中携带控制信息：

TCP的可选字段（Option）里面，在RNextKeyID字节后面单独再用一个字节控制字段（Control）来对密钥的协调进行控制，这个字节可以表示256种保留的控制信息，目前我们启用的是：

（a）控制字段为0Xff，表示接收方不同意使用所述新的密钥（没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏）；

（b）控制字段为0Xfe，表示同意使用所述新的密钥，但是没有配置好；

（c）控制字段为0Xfd，表示密钥选择权交换。

其中（a）和（b）保留的控制信息用于接收方的回应报文中，而（c）保留的控制信息是用于发送方的报文中。

更新密钥的发送方维护两个计数器：第一计数器和第二计数器，分别对应两个变量：Counter1和Counter2，这两个变量的上限值可以由运营商的个人情况自行指定，对于Counter1,可以利用这个变量来限制发送方选取密钥的次数，超过Counter1上限的询问将触发密钥选择权的交换，即，当密钥协调的次数超过运营商设定的上限值的时候，发送方则认为接收方的可用的密钥配置数量大大少于自己的数据库中可用的密钥配置数量，为了加速密钥协调的过程，应该把密钥选择权交予对方。对于Counter2，可以利用这个变量来限制发送方等待接收方配置密钥的次数，超过Counter2上限的等待将触发发送方重新选择密钥来进行协调，即，当发送方发现接收方在多次会话后仍然没有配置好要求的密钥，则认为接收方没有该密钥或者配置困难，于是重新选择更新的密钥。

具体地，若接收方通过TCP报文的可选字段中携带控制信息（0Xff）告知所述发送方，接收方不同意使用所述新的密钥，则所述发送方判断自身维护的第一计数器（Counter1）是否超限；

若所述第一计数器未超限，则发送方设置所述第一计数器的值加1（Counter1＝Counter1＋1，可表示为Counter1++），重新选择新的密钥并告知接收方；

若所述第一计数器超限，则发送方初始化第一计数器（即将Counter1置为初始值），通过在TCP报文的可选字段中携带控制信息（0Xfd）发送给接收方，告知发送方密钥选择权交换，由发送方重新选择新的密钥。

若接收方通过TCP报文的可选字段中携带控制信息（0Xfe）告知所述发送方，接收方同意使用所述新的密钥，但是当前没有配置好所述新的密钥，则所述发送方判断自身维护的第二计数器（Counter2）是否超限；

若所述第二计数器未超限，则所述发送方设置所述第二计数器的值加1（Counter2＝Counter2＋1，可表示为Counter2++），在下一次与接收方的会话中重新要求所述接收方使用所述新的密钥；

若所述第二计数器超限，则发送方初始化第二计数器（即将Counter2置为初始值），并判断所述第一计数器是否超限；若所述第一计数器未超限，则发送方设置所述第一计数器的值加1，重新选择新的密钥并告知接收方；若所述第一计数器超限，则发送方初始化第一计数器，通过在TCP报文的可选字段中携带控制信息（0Xfd）发送给接收方，告知发送方密钥选择权交换，由发送方重新选择新的密钥。

下面以具体应用示例进一步描述本发明：

在下面的应用示例中，不失一般性并且为了简化说明，我们假设Counter1的上限为2，即：允许发送方选择两次密钥，如果不成功，则交换密钥选择权。同样，我们假设Counter2的上限为2，即：允许发送方等待两次会话来让接收方配置密钥，一旦超过两次会话，则触发重新选取密钥动作。

图3是一个发送方视角的状态转移图（假定Counter1上限为2并且Counter2的上限也是2），在其中我们定义以下状态：

301：当前会话用ID为1的旧密钥，但是发现这个密钥不再安全（过期，被攻击或者被破坏），于是要求下一次使用ID为2的密钥，并且在本地准备好这个密钥。

302：对方配置好所要求的密钥ID为2的密钥，并且开始正常通信。

303：由于对方还没有配置好密钥，所以本次通信还是用旧的ID为1的密钥，但是Counter2++。

304：所要求的ID为2的密钥在对方数据库中是不可用状态（数据库中没有，在对方环境中被攻击或者被破坏），则本次通信还用ID为1的密钥进行通信，但是重新选择新的ID为3的密钥来进行协调。此时Counter1++并且Counter2重新置为1。

305：由于Counter1超出界限值，触发交换密钥选择权动作。

306：对方配置好所要求的密钥ID为3的密钥，并且开始正常通信。

状态转移条件：

301------>302:对方同意并准备好ID=2的密钥

301------>303:对方同意使用ID=2的密钥，但是尚未配置好

301------>304:对方由于原因（ID=2的密钥不存在，被攻击或者被破坏）不同意使用ID=2的密钥。

303------>302:对方同意并准备好ID=2的密钥

303------>304:对方在Counter2超出界限值后仍然没有配置好所需的密钥。

303------>306:对方同意并准备好ID=3的密钥

304------>303:对方同意使用ID=3的密钥，但是尚未配置好

304------>305:对方由于原因（ID=3的密钥不存在，被攻击或者被破坏）不同意使用ID=3的密钥。

304------>306：对方同意并准备好ID=3的密钥

概况来说，当发送方要求下一次不再使用现在ID为1的密钥通信（原因可能是这个密钥过期，或者是在发送方的环境中这个密钥被攻击或者被破坏），而使用发送方已经准备好的ID为2的密钥，于是发送方发送报文中的字段为KeyID:1,RNextKeyID:2，并且初始化Counter1=1;Counter2=1。下面将出现不同的情况，具体见图3：

如果接收方有ID为2的密钥并且已经配置好，那么下一次通信将使用ID为2的密钥来生成认证码。

如果这时候接收方没有ID为2的密钥，那么接收方可以在RNextKeyID字段中用0Xff来通知要求使用新密钥的那一方，这时候发送方将重新选取一个新密钥ID为3，放在报文的RNextKeyID中，发送过去,并且在本地Counter1++，Counter2=1。如果这时候接收方还是以0Xff来回应，则发送方发现Counter1已经为2，所以在RNextKeyID中填上0Xfd来交换密钥选择权，让接收方自己选择在本地数据库中有并且配置好的密钥来交互，然后双方交换角色，重复上面的过程。

如果在第一次交互的时候，接收方有这个密钥，但是没有配置好，那么可以在RNextKeyID中填上0Xfe来通知发送方，发送方这时候Counter2++，让接收方有足够的时间来配置密钥，但是当下一次会话的时候，接收方还没有以要求的密钥计算认证部分，则发送方默认为接收方没有这个ID的密钥并重新选取密钥，这时候变成第二种情况并重复上面的过程。

在以下部分，阐述了常见的三种异常处理的方式。

情况1：见图4，

步骤401：发送方发现ID为1的密钥不安全，自己配置好ID为2的密钥并且发送报文KeyID=1;RNextKeyID=2给接收方，请求更新密钥为ID=2；

步骤402：接收方发现自己没有ID=2的密钥或者这个密钥也不安全，不能使用ID=2的密钥，于是他发送KeyID=1;RNextKeyID=0Xff通知发送方；

步骤403：接收方于是重新选择密钥为ID=3,Counter1++,Counter2=1，并且发送KeyID=1;RNextKeyID=3给接收方；

步骤404：接收方发现这个为3的密钥还是不能用（数据库中没有，或者也是过期或者不安全的），于是他继续用KeyID=1;RNextKeyID=0Xff来通知发送方；

步骤405：发送方发现现在的Counter1已经为2，意识到接收方的数据库中可用的密钥比较少，于是发送KeyID=1;RNextKeyID=0Xfd来告诉接收方交换密钥的选择权，让接收方自己选择密钥；

步骤406：接收方选择ID=4的密钥，并用KeyID=1;RNextKeyID=4来通知发送方已经选择了ID=4的密钥；

步骤407：发送方用ID=4的密钥开始正常通信。

情况2，见图5：

步骤501：发送方发现ID为1的密钥不安全，自己配置好ID为2的密钥并且发送报文KeyID=1;RNextKeyID=2给接收方，请求更新密钥为ID=2；

步骤502：接收方发现ID=2的密钥虽然存在，但是没有正确配置，需要时间配置，于是发送KeyID=1;RNextKeyID=0Xfe；

步骤503:发送方收到后，延长时间限，但是本次通信仍然用ID=1进行通信，所以发送KeyID=1;RNextKeyID=2，在本地，Counter2++；

步骤504:接收方配置完毕，发送KeyID=2;RNextKeyID=2来通知发送方密钥准备完毕并且用ID=2来认证报文消息；

步骤505：发送方收到后同意ID=2，异常消失，正常通信开始。

情况3，见图6

步骤601：发送方发现ID为1的密钥不安全，自己配置好ID为2的密钥并且发送报文KeyID=1;RNextKeyID=2给接收方，请求更新密钥为ID=2；

步骤602：接收方发现ID=2的密钥虽然存在，但是没有正确配置，需要时间配置，于是发送KeyID=1;RNextKeyID=0Xfe；

步骤603：发送方收到后，延长时间限，但是本次通信仍然用ID=1进行通信，所以发送KeyID=1;RNextKeyID=2，在本地Counter2++；

步骤604：接收方由于其他原因，配置仍然没有完成，于是发送KeyID=1;RNextKeyID=0Xfe来通知发送方；

步骤605：发送方这时候认为接收方没有该密钥，于是重新选择ID=3的密钥，发送KeyID=1;RNextKeyID=3。在本地Counter1++,Counter2=1；

步骤606:接收方发现ID=3的密钥虽然存在，但是没有正确配置，需要时间配置，于是发送KeyID=1;RNextKeyID=0Xfe；

步骤607:送方收到后，延长时间限，但是本次通信仍然用ID=1进行通信，所以发送KeyID=1;RNextKeyID=3，在本地，Counter2++；

步骤608:接收方由于其他原因，配置仍然没有完成，于是发送KeyID=1;RNextKeyID=0Xfe来通知发送方；

步骤609:发送方这时候发现Counter2已经为2并且Counter1也是2，于是认为接收方没有该密钥，于是交换密钥选择权，发送KeyID=1;RNextKeyID=0Xfd给接收方；

步骤610：接收方选择ID=4的密钥，并用KeyID=1;RNextKeyID=4来通知发送方已经选择了ID=4的密钥；

步骤611：发送方用ID=4的密钥开始正常通信。

本发明实施例的基于TCP的密钥协调系统，包括发送方和接收方，所述发送方用于和接收方进行密钥协调过程中，要求接收方使用新的密钥；所述接收方用于若当前无法使用所述新的密钥，则通过在TCP报文的可选字段中携带控制信息发送给发送方，将自身密钥使用情况告知发送方。

在实际应用中，有一种最坏的情况，就是双方一直互相交换密钥选择权但是迟迟没有协商成功，这个时候是因为双方可供使用的密钥交集数量太少，运营商可以在这种情况下及时更换双方数据库中的密钥。

综上所述，本发明的主要内容在于利用TCP的可选字段来处理在认证过程中由于一方的密钥没有准备好而出现的异常的情况。具体来说，当一方没有准备好密钥的时候，利用RNextKeyID字段的一些保留的控制信息和两个计数器来向要求更新密钥的那一方说明没有准备好的情况，接收方根据这些保留消息内容和计数器中的数值来做动作协调通信，解决异常。

当然，本发明还可有其它多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (6)

1.一种基于TCP的密钥协调方法，其特征在于，

发送方和接收方进行密钥协调过程中，发送方要求接收方使用新的密钥时，若接收方当前无法使用所述新的密钥，则接收方通过在传输控制协议TCP报文的可选字段中携带控制信息发送给发送方，将自身密钥使用情况告知发送方；

其中，所述TCP报文的可选字段中携带控制信息具体是指：TCP报文的新的密钥标识RNextKeyID字段中携带控制信息，或者，TCP报文的控制字段中携带控制信息；

所述TCP报文的RNextKeyID字段中携带控制信息，具体是指：RNextKeyID字段中的0XF0～0XFF用作控制信息，其中：

(1)若RNextKeyID字段为0Xff，则表示没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏；

(2)若RNextKeyID字段为0Xfe，则表示同意使用所述新的密钥，但是没有配置好；

(3)若RNextKeyID字段为0Xfd，则表示密钥选择权交换；

所述TCP报文的控制字段中携带控制信息，具体是指：RNextKeyID字段后的1字节控制字段用于携带控制信息，其中：

(1)若控制字段为0Xff，则表示没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏；

(2)若控制字段为0Xfe，则表示同意使用所述新的密钥，但是没有配置好；

(3)若控制字段为0Xfd，则表示密钥选择权交换。

2.如权利要求1所述的方法，其特征在于，

所述接收方当前无法使用所述新的密钥具体是指下述两种情况之一：

(1)接收方不同意使用所述新的密钥；

(2)接收方同意使用所述新的密钥，但是当前没有配置好所述新的密钥。

3.如权利要求2所述的方法，其特征在于，

所述接收方不同意使用所述新的密钥的情况包括：接收方没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏。

4.如权利要求2所述的方法，其特征在于，

若接收方通过TCP报文的可选字段中携带控制信息告知所述发送方，接收方不同意使用所述新的密钥，则所述发送方判断自身维护的第一计数器是否超限；

若所述第一计数器未超限，则发送方设置所述第一计数器的值加1，重新选择新的密钥并告知接收方；

若所述第一计数器超限，则发送方初始化第一计数器，通过在TCP报文的可选字段中携带控制信息发送给接收方，告知发送方密钥选择权交换，由发送方重新选择新的密钥。

5.如权利要求2所述的方法，其特征在于，接收方同意使用所述新的密钥，但是当前没有配置好所述新的密钥的具体过程包括：

若接收方通过TCP报文的可选字段中携带控制信息告知所述发送方，接收方同意使用所述新的密钥，但是当前没有配置好所述新的密钥，则所述发送方判断自身维护的第二计数器是否超限；

若所述第二计数器未超限，则所述发送方设置所述第二计数器的值加1，在下一次与接收方的会话中重新要求所述接收方使用所述新的密钥；

若所述第二计数器超限，则发送方初始化第二计数器，并判断第一计数器是否超限；若所述第一计数器未超限，则发送方设置所述第一计数器的值加1，重新选择新的密钥并告知接收方；若所述第一计数器超限，则发送方初始化第一计数器，通过在TCP报文的可选字段中携带控制信息发送给接收方，告知发送方密钥选择权交换，由发送方重新选择新的密钥。

6.一种基于TCP的密钥协调系统，包括发送方和接收方，其特征在于，

所述发送方用于和接收方进行密钥协调过程中，要求接收方使用新的密钥；

所述接收方用于若当前无法使用所述新的密钥，则通过在传输控制协议TCP报文的可选字段中携带控制信息发送给发送方，将自身密钥使用情况告知发送方；

其中，所述TCP报文的可选字段中携带控制信息具体是指：TCP报文的新的密钥标识RNextKeyID字段中携带控制信息，或者，TCP报文的控制字段中携带控制信息；

所述TCP报文的RNextKeyID字段中携带控制信息，具体是指：RNextKeyID字段中的0XF0～0XFF用作控制信息，其中：

(1)若RNextKeyID字段为0Xff，则表示没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏；

(2)若RNextKeyID字段为0Xfe，则表示同意使用所述新的密钥，但是没有配置好；

(3)若RNextKeyID字段为0Xfd，则表示密钥选择权交换；

所述TCP报文的控制字段中携带控制信息，具体是指：RNextKeyID字段后的1字节控制字段用于携带控制信息，其中：

(1)若控制字段为0Xff，则表示没有所述新的密钥，或者所述新的密钥被攻击，或者所述新的密钥被破坏；

(2)若控制字段为0Xfe，则表示同意使用所述新的密钥，但是没有配置好；

(3)若控制字段为0Xfd，则表示密钥选择权交换。