根据无线 USB 规范 1.0，在 TrustTimeout（可信超时）后，旧的成对临时密钥（Pairwise Temporal Key，PTK）过期，需要更换。但该规范并没有明确定义何时应抛弃旧的 PTK。在TrustTimeout 后，无线 USB 主机可以立即删除 PTK，或永久保留，也可以保留某段时间。

本文根据这一特点提出了一种新的 PTK 管理方法。它有两个新颖之处：

a)在TrustTimeout 后的 ReconnectTimeout 期间保留 PTK
b)当主机检测到 TrustTimeout 时，发送 Keep_Alive IE，并发起四方握手（four-way handshake）。

介绍

无线 USB 设备向无线 USB 主机发出一个 DN_Connect来发起连接。收到连接后，主机开始一个关联过程，以取得一个主密钥和连接上下文（CC）。这个密钥其后用于两端的认证过程，以取得临时密钥，即成对临时密钥（PTK）和成组临时密钥（GTK）。这些密钥用于主机与设备之间的加密通信。这里我们讨论 PTK，它可以用于交换最多 248 个数据包。如果这一通信能持续下去的话，这一数字等效于 9 年的时间。但PTK 只在 TrustTimeout 提供的连接时间内有效。当设备遇到一个 TrustTimeout 时，将发起一个重新连接过程，并且它一定要使用加密的封包。而 TrustTimeout 以后，主机就可以丢弃PTK。规范中并没有明确定义何时应丢弃 PTK。由于主机与设备的 TrustTimeout 窗口可能并不相同，因此可能出现下节所讨论的问题。

问题

我们看下面的情况：

A.这是一种普通情况，主机在自己 TrustTimeout 前就收到一个重新连接请求，因为有一个设备已经超过了自己的 TrustTimeout。这种情况下，主机有 PTK，可以对重新连接请求进行解密，从而完成一次成功的重新连接。我们不对这种情况做进一步讨论。

B.主机在 TrustTimeout 后立即删除 PTK。这种情况下，设备的重新连接请求（即加密的 DN_Connect）无法被主机解密。因此，主机不可能简单地开始四方握手，而设备也不能再次恢复以前的上下文。设备将需要进入未连接状态，并再次从头起动连接过程，因为连接上下文已丢失。这与重新连接过程的目的相冲突。

C.主机可以 在TrustTimeout 后选择保留 PTK，直到收到 DN_Connect，对DN_Connect进行处理并生成新的 PTK。但是，设备只能重试 DN_Connect 六次。如果所有 DN_Connect 均由于数据包损坏或通道不良而丢失，则主机会继续保留 PTK 和上下文（实际上是无限期保留），规范 并没有定义这一点。这是系统资源的一种浪费，并且有可能被黑客利用。

根据我们讨论的这些情况，显然主机需要在 TrustTimeout 以后（PTK 过期）保留 PTK。但在规范中，并没有明确定义下列内容：

持续时间应多长
如果没有收到 DN_Connect，主机需要采用哪种动作
为解决这些问题，建议采用下列方案。

解决方案
我们提出了一种改进的 PTK 管理方法：
首先，建议将 PTK 保留一个"ReconnectTimeout（重新连接超时）时间。"ReconnectTimeout定义为 TrustTimeout 后的一个窗口，在这期间，无线 USB 主机继续保持 PTK 为活动状态。ReconnectTimeout 帮助重新连接过程，并符合 PTK 的安全要求。

其次，定义一个"host initiated reconnect"（主机发起的重新连接）事件，即当从主机角度检测到 TrustTimeout 时，主机将发送 Keep_Alive IE，并发起一个四方握手。

"device initiated reconnect"（设备发起的重新连接）是已经存在的事件，每当设备获得一个 TrustTimeout 时它都可以发生。

在 ReconnectTimeout 期限内，新定义的"host initiated reconnect"过程和现有的"device initiated reconnect"过程会同时工作，以提高重新连接过程的成功机率。

图 2 描述了 ReconnectTimeout、 "host initiated reconnect"与"device initiated reconnect"的一般概念。详细方法如下所示。

图 2 ReconnectTimeout、主机发起的重新连接（host initiated reconnect）与设备发起的重新连接（device initiated reconnect）

在 ReconnectTimeout 期间，建议"host initiated reconnect"与"device initiated reconnect"可以同时工作，使无线 USB 设备能够与无线 USB 主机完成正确的重新连接。如果失败，PTK 将在 ReconnectTimeout 之后被摧毁。两种重新连接过程定义如下：

主机发起的重新连接（host initiated reconnect）：假设主机检测到 TrustTimeout，并且可能由于数据包损坏而没有收到 DN_Connect，我们建议主机发送 Keep_Alive IE 而为设备提供一个机会窗口。当设备用 DN_Alive 或 DN_Connect（均作加密）作出响应时，主机将重新开始四方握手过程，并完成一个设备的"重新连接"（reconnect）。此方法主要用于主机检测到一个 TrustTimeout，但设备尚未检测到的情况。此种情况下，造成TrustTimeout 的原因是来自设备的数据包丢失。因此，在 TrustTimeout 后，主机将再发三个 Keep_Alive_IE，并等待任何设备的 DN_Alive 或DN_Connect 通告（两者均加密），用于 ReconnectTimeout。

设备发起的重新连接（device initiated reconnect）：假定设备首先检测到了TrustTimeout，则设备会向主机发送最多六次 DN_Connect（加密）。如果无线 USB 主机未检测到 TrustTimeout，则 PTK 被保留，且 DN_Connect 被成功解密。如果无线 USB 主机也检测到了一个 TrustTimeout，但在定义的"ReconnectTimeout"时间内 PTK 仍被保留，则 DN_Connect 也能成功解密。ReconnectTimeout 可帮助完成一次成功的重新连接。

为实现这两种重新连接过程，建议"ReconnectTimeout"为 390 ms。以下是详细计算过程：
假设每个超帧（superframe）（65 ms）有"n"个微调度管理指令（Micro-scheduled Management Command，MMC），详细计算过程如下：

对于"主机发起的重新连接"：ReconnectTimeout = 三个 KeepAlive_IE 的 KeepAlive Time，即大约 3 x 65 ms x 1/(n) = 195 ms/(n)
对于"设备发起的重新连接"：ReconnectTimeout = 六个 DN_Connect 的 DN_Connect Time，即大约6x65 ms x 1/(n) = 390 ms/(n)

由于"主机发起的重新连接"与"设备发起的重新连接"两类过程可以同时发生，ReconnectTimeout 被定义为 390ms/(n)。因此，考虑到最差情况，建议的ReconnectTimeout 为 390 ms。

总结
总之，无线 USB 规范没有明确地指示出 TrustTimeout 以后的 PTK 管理。这种模糊性有可能导致重新连接的失败，或系统资源的浪费。本文对 ReconnectTimeout（这期间保留 PTK）作了清晰的定义。另外，如在 DN_Connect 成功到达主机以前，主机监测到了 TrustTimeout，则使用一个"主机发起的重新连接"过程。有了这两种机制，就可以解决 TrustTimeout 以后的 PTK 管理问题。