快速配对程序

过程

探索器不会立即调用任何常规 BR/EDR 或 BLE 绑定过程，而是首先针对基于密钥配对特性启用通知，然后将表 1.1 中的数据写入其中。

处理来自快速配对查找器的写入请求时，快速配对提供程序应执行以下操作：

  1. 如果存在可选的“公钥”字段：
    1. 如果设备未处于配对模式，则忽略写入并退出。
    2. 否则：
      1. 使用收到的公钥（secp256r1 椭圆曲线上的 64 字节点）、预安装的防仿冒私钥（也是 secp256r1）和椭圆曲线 Diffie-Hellman 算法，以生成 256 位 AES 密钥。
      2. 使用 SHA-256 对 256 位 AES 密钥进行哈希处理。
      3. 获取结果的前 128 位。这是防欺骗 AES 密钥，将在下一步中使用。

  2. 使用 AES-128，尝试解密该值。由于该值是一个 16 字节的 AES 分块，因此不需要 IV 或多块加密模式。

    1. 要使用哪个键：
      1. 如果在第 1 步中生成了防仿冒 AES 密钥，请使用该密钥。
      2. 否则，请尝试持久保留的账号密钥列表中的每个密钥。
    2. 如果某个密钥成功解密了该值，请中断该密钥的解密，然后继续执行下一步。

    3. 如果输出与表 1.2.1 或表 1.2.2 中的格式匹配（即，包含快速配对提供程序的当前 BLE 地址或快速配对提供程序的公共地址），则相应值已成功解密。

      注意：包装盒末尾还附有盐。应尽可能跟踪这些盐，如果 Provider 收到的请求包含已使用的盐，则应忽略该请求，以防止重放攻击。

    4. 作为跟踪盐的替代方法，如果写入中包含提供程序的私有地址，另一种防止重放攻击的方法就是将下一个可解析私有地址轮替的时间提前，以便在下一次基于密钥配对写入被接受之前进行轮替。

  3. 如果没有密钥可以成功解密该值，则忽略写入并退出。

    1. 记录这些失败情况。失败次数达到 10 时，所有新请求立即失败。5 分钟后、开机后或成功后重置失败计数。

  4. 否则，将成功的密钥保存为 K。将此 K 标记为可用于解密在此 LE 链接上收到的通行密钥和个性化名称写入操作，但不能将其用于其他写入操作，也不能在任何其他链接上写入任何写入操作。如果配对尚未开始，则启动计时器，在 10 秒后舍弃 K。如果此 LE 链路断开连接，也舍弃 K。

  5. 通过将类型与提供程序的 BR/EDR 地址串联，然后使用随机字节块（即盐）填充数据包的其余部分，生成表 1.3 中所示的 16 字节原始响应。

  6. 使用 K 加密原始响应以生成表 1.4 中所示的 16 字节加密响应。通过关于基于密钥的配对特征的通知来发送此信息。

  7. 读取请求标志：

    1. 如果请求的标志字节将位 2 设置为 1，请使用个性化名称通知其他数据特征。
    2. 如果请求的标志字节将位 1 设置为 1：
      1. 这表示查找器正在请求提供程序启动与查找器的 BR/EDR 地址（以字节 8-13 为单位）的绑定。
      2. 向寻找者的 BR/EDR 地址发送配对请求。配对请求必须如下文所述（“配对期间”步骤）。
      3. 需要这样做的原因：让提供程序发起启动可以解决某些设备上的问题。
    3. 如果请求的标志字节将位 1 设置为 0：
      1. 最多等待 10 秒，等待配对请求。如果未收到任何消息，则退出。
      2. 请注意，这可能是来自其他地址（探索者的公共地址，而不是其可解析的私有地址）的 BR/EDR 请求。在配对过程中，我们将重新验证请求设备是否持有 K。

  8. 在配对期间：

    1. 从搜索程序收到配对请求/响应数据包时：如果请求中的设备功能为 NoInput/NoOutput，请结束配对，以避免使用 Just Works 配对方法。
    2. 对于提供方发送的配对请求/响应数据包：将“Device Capabilities”字段设置为 Display/YesNo，将“Authentication 要求”设置为 MITM Protection required（要求提供 MITM 保护）。这会触发数字比较配对方法（在 Android 上也称为“通行密钥确认”）。我们依靠此信息来确认请求设备确实是快速配对查找器，并且没有中间人。查看示例。
    3. 需要这样做的原因：带外配对方法更合适，但平台不会在所需的全部 Android 版本上公开它。

  9. 当需要确认通行密钥时，最多等待 10 秒，以便写入通行密钥特征。

    1. 通常，使用此配对方法时，用户会确认每个设备屏幕上显示的通行密钥是相同的。相反，仅针对此配对，我们会通过 BLE 传输数据，并使用可信的预共享密钥进行加密。
    2. 请注意，请勿针对具有屏幕或键盘的设备采取此方法，因为这会略微破坏 MITM 保护。因此，快速配对功能目前不支持这些设备类型。
    3. 如果 10 秒计时器到期，且未写入通行密钥，则舍弃 K。

  10. 当将值写入通行密钥特征时，这就是加密的通行密钥块。使用 K 解密该密钥以生成原始通行密钥块，格式如特征：通行密钥 > 表 2.2 -（类型 = 探索者的通行密钥）中所示。

  11. 如果解密失败，忽略写入并舍弃 K。

  12. 否则，原始通行密钥块会包含一个 6 位数的通行密钥 PSeeker，这是寻找者期望的通行密钥。

  13. 将 PSeeker 与我们自己的预期通行密钥 PProvider 进行比较。

    1. 如果值相等，请在确认时回复“是”。
    2. 否则，请在确认消息时回复“否”，导致配对失败。

  14. 无论配对是否失败，都生成另一个原始通行密钥块，格式如特征：通行密钥 > 表 2.2 中所示，包含我们自己的预期通行密钥 PProvider。

    1. 确保该块具有正确的类型（提供商的通行密钥；参见表格）。 注意：请勿重复使用从探索器收到的通行密钥分块中的盐。生成一个新的随机值。

  15. 使用 K 加密原始通行密钥分块，并通过关于通行密钥特征的通知发送生成的加密通行密钥分块。

  16. 如果搜寻者收到并解密正确的通行密钥 P，探索程序也将对确认回复“yes”，并且配对成功。

    1. 如果配对成功，则将 K 标记为可用于在此 LE 链接上解密账号密钥写入，但不能用于任何后续的通行密钥写入或任何其他链接上的任何写入。启动计时器，以便在 10 秒后舍弃 K。此外，在尝试写入账号密钥后，还应舍弃 K，按照第 4 步，如果 LE 链接断开连接。
    2. 如果配对失败，请舍弃 K。

  17. 将设备功能字段切换回默认 I/O 功能，并将身份验证要求切换回默认值，以便新配对按预期继续。

请注意，对于不需要绑定的提供程序，搜寻程序不会向提供程序发送配对请求，即跳过第 8 步 - 跳过第 17 步。此外，帐号关键特征中使用了“K”。

示例
示例 1：尝试成功配对（无中间人）。
示例 2：配对尝试失败，且使用中间人。