Google Fast Pair

Google Fast Pair正是利用了前面所说的LE配对认证后生成的LTK与经典蓝牙所需的link key可以互相转换的特性来定义的一种更快速高效，用户体验更好的配对模式。

所有使用Google Fast Pair的蓝牙产品都必须在Google注册，Google会为每个产品分配一个Model ID和一个Anti-Spoofing Public/Private Key Pair密钥对。其中Model ID和Anti-Spoofing Private Key Pair密钥会一直保存在蓝牙产品中，会在后面的配对过程中使用到，Android手机可以从Google内部查询到私钥对应的公钥。Google Fast Pair只能在两个都注册过的产品之间使用，IOS手机暂时就不可以。

除了注册以外，蓝牙产品还需要在产品GATT上注册UUID为0xFE2c的Fast Pair Service服务，可被SDP查到，后续的Google Fast Pair流程很大一部分都是在这个FPS服务上完成的。

支持GFP的蓝牙产品还需要在内部维持一个账户密钥池，能够存储至少5个账户密钥，用以维持与不同手机的配对结果。

对于Google Fast Pair来说，定义了2种角色：Fast Pair Seeker和Fast Pair Provider。Seeker通常是手机，Provider是其他蓝牙产品，如耳机等。同时Seeker做GAP Central role, Provider做GAP Peripheral role。同时还要求Provider必须至少支持HFP或A2DP.

Google Fast Pair对用户体验最大的改善就是用户不再需要一步步进入手机的蓝牙设置界面去寻找设备。它的实现方式就是通过前面注册的Model ID。支持GFP的蓝牙产品在开起后如果没有连接，就会一直广播。这与产品是否处于经典蓝牙的discovery模式无关。

如果产品处于discovery模式，那么产品就会通过FPS服务广播Model ID，手机收到Model ID后发现这是一个支持GFP的蓝牙产品，通过Model ID可以在Google内部查询到产品的相关信息，直接显示在手机界面上。用户无需一步步进入手机的蓝牙设置就能看到蓝牙产品，点击显示界面上的配对，就能开始进行配对。

如果产品不处于discovery模式，那么产品就会通过FPS服务广播Fast Pair Account Data账户信息，手机收到账户信息后经过对比发现与手机所属相同账户，手机就会自动发起配对，甚至都不需要用户操作。

Fast Pair Service服务包含有3个特征：

我们用其中的Key-based Pairing特征来进行配对。

对于首次配对，蓝牙产品肯定是没有手机账户的账户密钥的，所以此时它无法广播账户密钥信息。于是需要切换至discovery模式。我认为这个可以是用户手动切换，因为蓝牙产品是无法判断即将要配对的手机是否是已配对手机。如果蓝牙产品已经有账户信息，而用户没有切换至discovery模式，那么它广播的账户信息与手机不一致，手机界面是不会显示给用户它的相关信息的，此时用户就会发现问题，从而手动切换模式。

切换至discovery模式后，蓝牙产品就会广播Model ID，手机收到后发现是GFP产品显示到界面，用户才可以点击开始配对。配对流程如下：

1. 首先Seeker发起Encrypted Request，是利用Key-based Pairing服务发送。请求里面包含了加密了的Raw Request字段和可选的Public Key字段。用Anti-Spoofing Public Key 密钥加密的，这个应该是手机通过Model ID从Google联网查到的。
2. Provider就用收到的Public key与注册时给出的Anti-Spoofing Private Key计算出一个256位的AES Key。这个256位AES Key的前128位就是Anti-Spoofing AES Key.
3. 然后用这个Anti-Spoofing AES Key来解密收到的加密数据，如果失败，记录下来，如果相同设备失败超过10次，那么拒绝它的请求5分钟。如果成功，记录下这个K，用以这次链接后续步骤等待配对的真正开始，如果10s还没有开始，那么这个K也要抛弃掉。
4. Provider回复加了密的Raw Response，其中包含了Provider的Public Key和伪随机数。并用第3步中成功解密的密钥K来加密
5. 如果第1步里的Seeker发送的Raw Request中请求了Provider开启discoverable，那么Provider此时就向Seeker发起pairing request。如果没有请求开启discoverable，那么Provider就等10s钟等Seeker主动发起pairing request。
6. 如果收到的seeker发起的或者回复的Pairing Request/Pairing Response里面显示seeker的io capability是NoInput/NoOutput，那么就需要终止配对，因为GFP为了保证安全不支持justworks模式。
7. 第5步中Provider发出的或者回复的Pairing Request/Pairing Response中也需要把io capability设置为Display/YesNo，来使用Numeric Comparison模式，此时尽管产品可能并没有显示屏，但是没有关系，后面会用PassKey特征来解决这个问题。如果能采用OOB模式就更好了，不过GFP没有强求。
8. 此时对比4.1节中的LE配对模式，可以发现，FPS在完成Public key的部分后，剩下的commitment和伪随机数的交换依然可以用LMP继续完成。
9. 由于GFP走的Numeric Comparison，而不是justworks，所以还有6位比较数的显示与用户确认部分。这部分就需要用到FPS的Passkey特征。它的方法是用前面的密钥K来对比较数加密，然后通过Passkey特征服务用蓝牙传输给对方。如果10s没有收到比较数，那么丢弃这个密钥K。
10. Provider比较收到的Seeker的比较数与自己的比较数是否一致，如果一致那么回复确认并发送自己的比较数
11. Seeker比较收到的Provider比较数与自己的比较数是否一致，如果一致那么回复确认。
12. 如果Seeker确认，那么配对认证成功。这个密钥K将被Seeker用以加密账户密钥，但是后续的Passkey和其他连接都不再使用这个密钥，并会在10s丢弃这个密钥。
13. Provider将io capability返回到NoInput/NoOutput，那样新的非GFP配对也可以继续进行。
14. Pair结束以后，seeker会把账户密钥通过Account key特征服务发送给Provider，用之前的密钥K加密。Provider会把账户密钥保存到自己的账户密钥池中，用来下次配对使用。

15. 然后，重要的是，LE生成的LTK会通过算法转化成经典蓝牙的link key。同时provider会通过HFP或者A2DP向Seeker发起经典蓝牙的连接，用这个转化的link key完成配对，无需重新认证。

    
    

对于二次配对情况，手机已经拥有账户信息，于是无需用户将蓝牙产品切换至discovery模式，它会自动广播账户信息。

1. 手机收到后与自己账户比较后显示到界面，（用户点击开始配对）这个地方存疑，应该也可以直接开始连接。
2. 此时如果是已经配对过的手机，是包含前次配对记录的LTK的，可以直接加密，成功后即可正常使用
3. 如果是未配对过的手机使用相同账户，那么手机应该可以从Google内部下载到相关账户的密钥，从而完成加密，正常使用。

GFP由于进行的是numeric comparison认证，对于无显示屏的蓝牙产品本来只能用justworks认证，现在可以用numeric comparison认证，更加安全。

从配对流程可以看出，Google其实就是在原有的配对流程上又增加了一层密钥，用这个密钥来将一些本来不加密的信息加密，或者本来不会暴露在蓝牙信道中的信息加密。比如numeric comparison中的比较数，因此这个密钥非常重要。而这个密钥是在产品一开始在Google注册的时候就一直保存在产品中了，虽然Google一直强调产品内部必须要有安全模块来管理这个密钥，但是依然有泄露的可能。为了保证安全性，一旦Google发现了密钥的泄露，比如不同设备使用相同密钥，那么使用这个密钥的产品将不再能使用GFP来配对，而由于这个密钥是出厂前设置，所以相当于这个产品永远都不能再使用GFP来配对了。

同时为了防止中间人追踪账户信息，Provider广播的账户信息中包含一个salt值，用来做账户信息过滤，并保证至少15分钟更换一次。

Provider与Seeker之间的Raw Request和Raw Response也包含了随机数用来做salt值，需要监控这个值，如果前后发送的相同的话，需要拒绝掉这个Request或Response。

采用比较数来认证的方式，可以防止中间人攻击，因为生成比较数的时候是根据伪随机数与Public key生成的，当有中间人的时候，无法保证伪随机数的相同，从而比较数不同。这一点与3.3.1中的方式是一致的。而在最后的比较数传输的过程中，因为中间人不知道密钥K，所以无法解密出比较数伪装，所以依然能防止中间人攻击。

Google的提前注册获得的Anti-Spoofing Private Key Pair私钥不能更改，会一直保存在蓝牙产品中，一旦泄露，就再也不能使用方便的GFP方式配对了。

但是Google的提前注册机制让它能够正确区分每一个蓝牙产品，能够应对 更加复杂的环境。当然，提前注册机制对厂商和Google自身的要求就多了很多，可能导致GFP的使用范围受限。