Google Fast Pair正是利用了前面所說的LE配對(duì)認(rèn)證后生成的LTK與經(jīng)典藍(lán)牙所需的link key可以互相轉(zhuǎn)換的特性來定義的一種更快速高效，用戶體驗(yàn)更好的配對(duì)模式。

所有使用Google Fast Pair的藍(lán)牙產(chǎn)品都必須在Google注冊(cè)，Google會(huì)為每個(gè)產(chǎn)品分配一個(gè)Model ID和一個(gè)Anti-Spoofing Public/Private Key Pair密鑰對(duì)。其中Model ID和Anti-Spoofing Private Key Pair密鑰會(huì)一直保存在藍(lán)牙產(chǎn)品中，會(huì)在后面的配對(duì)過程中使用到，Android手機(jī)可以從Google內(nèi)部查詢到私鑰對(duì)應(yīng)的公鑰。Google Fast Pair只能在兩個(gè)都注冊(cè)過的產(chǎn)品之間使用，IOS手機(jī)暫時(shí)就不可以。

除了注冊(cè)以外，藍(lán)牙產(chǎn)品還需要在產(chǎn)品GATT上注冊(cè)UUID為0xFE2c的Fast Pair Service服務(wù)，可被SDP查到，后續(xù)的Google Fast Pair流程很大一部分都是在這個(gè)FPS服務(wù)上完成的。

支持GFP的藍(lán)牙產(chǎn)品還需要在內(nèi)部維持一個(gè)賬戶密鑰池，能夠存儲(chǔ)至少5個(gè)賬戶密鑰，用以維持與不同手機(jī)的配對(duì)結(jié)果。

對(duì)于Google Fast Pair來說，定義了2種角色：Fast Pair Seeker和Fast Pair Provider。Seeker通常是手機(jī)，Provider是其他藍(lán)牙產(chǎn)品，如耳機(jī)等。同時(shí)Seeker做GAP Central role, Provider做GAP Peripheral role。同時(shí)還要求Provider必須至少支持HFP或A2DP.

Google Fast Pair對(duì)用戶體驗(yàn)最大的改善就是用戶不再需要一步步進(jìn)入手機(jī)的藍(lán)牙設(shè)置界面去尋找設(shè)備。它的實(shí)現(xiàn)方式就是通過前面注冊(cè)的Model ID。支持GFP的藍(lán)牙產(chǎn)品在開起后如果沒有連接，就會(huì)一直廣播。這與產(chǎn)品是否處于經(jīng)典藍(lán)牙的discovery模式無關(guān)。

如果產(chǎn)品處于discovery模式，那么產(chǎn)品就會(huì)通過FPS服務(wù)廣播Model ID，手機(jī)收到Model ID后發(fā)現(xiàn)這是一個(gè)支持GFP的藍(lán)牙產(chǎn)品，通過Model ID可以在Google內(nèi)部查詢到產(chǎn)品的相關(guān)信息，直接顯示在手機(jī)界面上。用戶無需一步步進(jìn)入手機(jī)的藍(lán)牙設(shè)置就能看到藍(lán)牙產(chǎn)品，點(diǎn)擊顯示界面上的配對(duì)，就能開始進(jìn)行配對(duì)。

如果產(chǎn)品不處于discovery模式，那么產(chǎn)品就會(huì)通過FPS服務(wù)廣播Fast Pair Account Data賬戶信息，手機(jī)收到賬戶信息后經(jīng)過對(duì)比發(fā)現(xiàn)與手機(jī)所屬相同賬戶，手機(jī)就會(huì)自動(dòng)發(fā)起配對(duì)，甚至都不需要用戶操作。

Fast Pair Service服務(wù)包含有3個(gè)特征：

我們用其中的Key-based Pairing特征來進(jìn)行配對(duì)。

對(duì)于首次配對(duì)，藍(lán)牙產(chǎn)品肯定是沒有手機(jī)賬戶的賬戶密鑰的，所以此時(shí)它無法廣播賬戶密鑰信息。于是需要切換至discovery模式。我認(rèn)為這個(gè)可以是用戶手動(dòng)切換，因?yàn)樗{(lán)牙產(chǎn)品是無法判斷即將要配對(duì)的手機(jī)是否是已配對(duì)手機(jī)。如果藍(lán)牙產(chǎn)品已經(jīng)有賬戶信息，而用戶沒有切換至discovery模式，那么它廣播的賬戶信息與手機(jī)不一致，手機(jī)界面是不會(huì)顯示給用戶它的相關(guān)信息的，此時(shí)用戶就會(huì)發(fā)現(xiàn)問題，從而手動(dòng)切換模式。

切換至discovery模式后，藍(lán)牙產(chǎn)品就會(huì)廣播Model ID，手機(jī)收到后發(fā)現(xiàn)是GFP產(chǎn)品顯示到界面，用戶才可以點(diǎn)擊開始配對(duì)。配對(duì)流程如下：

1. 首先Seeker發(fā)起Encrypted Request，是利用Key-based Pairing服務(wù)發(fā)送。請(qǐng)求里面包含了加密了的Raw Request字段和可選的Public Key字段。用Anti-Spoofing Public Key 密鑰加密的，這個(gè)應(yīng)該是手機(jī)通過Model ID從Google聯(lián)網(wǎng)查到的。
2. Provider就用收到的Public key與注冊(cè)時(shí)給出的Anti-Spoofing Private Key計(jì)算出一個(gè)256位的AES Key。這個(gè)256位AES Key的前128位就是Anti-Spoofing AES Key.
3. 然后用這個(gè)Anti-Spoofing AES Key來解密收到的加密數(shù)據(jù)，如果失敗，記錄下來，如果相同設(shè)備失敗超過10次，那么拒絕它的請(qǐng)求5分鐘。如果成功，記錄下這個(gè)K，用以這次鏈接后續(xù)步驟等待配對(duì)的真正開始，如果10s還沒有開始，那么這個(gè)K也要拋棄掉。
4. Provider回復(fù)加了密的Raw Response，其中包含了Provider的Public Key和偽隨機(jī)數(shù)。并用第3步中成功解密的密鑰K來加密
5. 如果第1步里的Seeker發(fā)送的Raw Request中請(qǐng)求了Provider開啟discoverable，那么Provider此時(shí)就向Seeker發(fā)起pairing request。如果沒有請(qǐng)求開啟discoverable，那么Provider就等10s鐘等Seeker主動(dòng)發(fā)起pairing request。
6. 如果收到的seeker發(fā)起的或者回復(fù)的Pairing Request/Pairing Response里面顯示seeker的io capability是NoInput/NoOutput，那么就需要終止配對(duì)，因?yàn)镚FP為了保證安全不支持justworks模式。
7. 第5步中Provider發(fā)出的或者回復(fù)的Pairing Request/Pairing Response中也需要把io capability設(shè)置為Display/YesNo，來使用Numeric Comparison模式，此時(shí)盡管產(chǎn)品可能并沒有顯示屏，但是沒有關(guān)系，后面會(huì)用PassKey特征來解決這個(gè)問題。如果能采用OOB模式就更好了，不過GFP沒有強(qiáng)求。
8. 此時(shí)對(duì)比4.1節(jié)中的LE配對(duì)模式，可以發(fā)現(xiàn)，F(xiàn)PS在完成Public key的部分后，剩下的commitment和偽隨機(jī)數(shù)的交換依然可以用LMP繼續(xù)完成。
9. 由于GFP走的Numeric Comparison，而不是justworks，所以還有6位比較數(shù)的顯示與用戶確認(rèn)部分。這部分就需要用到FPS的Passkey特征。它的方法是用前面的密鑰K來對(duì)比較數(shù)加密，然后通過Passkey特征服務(wù)用藍(lán)牙傳輸給對(duì)方。如果10s沒有收到比較數(shù)，那么丟棄這個(gè)密鑰K。
10. Provider比較收到的Seeker的比較數(shù)與自己的比較數(shù)是否一致，如果一致那么回復(fù)確認(rèn)并發(fā)送自己的比較數(shù)
11. Seeker比較收到的Provider比較數(shù)與自己的比較數(shù)是否一致，如果一致那么回復(fù)確認(rèn)。
12. 如果Seeker確認(rèn)，那么配對(duì)認(rèn)證成功。這個(gè)密鑰K將被Seeker用以加密賬戶密鑰，但是后續(xù)的Passkey和其他連接都不再使用這個(gè)密鑰，并會(huì)在10s丟棄這個(gè)密鑰。
13. Provider將io capability返回到NoInput/NoOutput，那樣新的非GFP配對(duì)也可以繼續(xù)進(jìn)行。
14. Pair結(jié)束以后，seeker會(huì)把賬戶密鑰通過Account key特征服務(wù)發(fā)送給Provider，用之前的密鑰K加密。Provider會(huì)把賬戶密鑰保存到自己的賬戶密鑰池中，用來下次配對(duì)使用。

15. 然后，重要的是，LE生成的LTK會(huì)通過算法轉(zhuǎn)化成經(jīng)典藍(lán)牙的link key。同時(shí)provider會(huì)通過HFP或者A2DP向Seeker發(fā)起經(jīng)典藍(lán)牙的連接，用這個(gè)轉(zhuǎn)化的link key完成配對(duì)，無需重新認(rèn)證。

    
    

對(duì)于二次配對(duì)情況，手機(jī)已經(jīng)擁有賬戶信息，于是無需用戶將藍(lán)牙產(chǎn)品切換至discovery模式，它會(huì)自動(dòng)廣播賬戶信息。

1. 手機(jī)收到后與自己賬戶比較后顯示到界面，（用戶點(diǎn)擊開始配對(duì)）這個(gè)地方存疑，應(yīng)該也可以直接開始連接。
2. 此時(shí)如果是已經(jīng)配對(duì)過的手機(jī)，是包含前次配對(duì)記錄的LTK的，可以直接加密，成功后即可正常使用
3. 如果是未配對(duì)過的手機(jī)使用相同賬戶，那么手機(jī)應(yīng)該可以從Google內(nèi)部下載到相關(guān)賬戶的密鑰，從而完成加密，正常使用。

GFP由于進(jìn)行的是numeric comparison認(rèn)證，對(duì)于無顯示屏的藍(lán)牙產(chǎn)品本來只能用justworks認(rèn)證，現(xiàn)在可以用numeric comparison認(rèn)證，更加安全。

從配對(duì)流程可以看出，Google其實(shí)就是在原有的配對(duì)流程上又增加了一層密鑰，用這個(gè)密鑰來將一些本來不加密的信息加密，或者本來不會(huì)暴露在藍(lán)牙信道中的信息加密。比如numeric comparison中的比較數(shù)，因此這個(gè)密鑰非常重要。而這個(gè)密鑰是在產(chǎn)品一開始在Google注冊(cè)的時(shí)候就一直保存在產(chǎn)品中了，雖然Google一直強(qiáng)調(diào)產(chǎn)品內(nèi)部必須要有安全模塊來管理這個(gè)密鑰，但是依然有泄露的可能。為了保證安全性，一旦Google發(fā)現(xiàn)了密鑰的泄露，比如不同設(shè)備使用相同密鑰，那么使用這個(gè)密鑰的產(chǎn)品將不再能使用GFP來配對(duì)，而由于這個(gè)密鑰是出廠前設(shè)置，所以相當(dāng)于這個(gè)產(chǎn)品永遠(yuǎn)都不能再使用GFP來配對(duì)了。

同時(shí)為了防止中間人追蹤賬戶信息，Provider廣播的賬戶信息中包含一個(gè)salt值，用來做賬戶信息過濾，并保證至少15分鐘更換一次。

Provider與Seeker之間的Raw Request和Raw Response也包含了隨機(jī)數(shù)用來做salt值，需要監(jiān)控這個(gè)值，如果前后發(fā)送的相同的話，需要拒絕掉這個(gè)Request或Response。

采用比較數(shù)來認(rèn)證的方式，可以防止中間人攻擊，因?yàn)樯杀容^數(shù)的時(shí)候是根據(jù)偽隨機(jī)數(shù)與Public key生成的，當(dāng)有中間人的時(shí)候，無法保證偽隨機(jī)數(shù)的相同，從而比較數(shù)不同。這一點(diǎn)與3.3.1中的方式是一致的。而在最后的比較數(shù)傳輸?shù)倪^程中，因?yàn)橹虚g人不知道密鑰K，所以無法解密出比較數(shù)偽裝，所以依然能防止中間人攻擊。

Google的提前注冊(cè)獲得的Anti-Spoofing Private Key Pair私鑰不能更改，會(huì)一直保存在藍(lán)牙產(chǎn)品中，一旦泄露，就再也不能使用方便的GFP方式配對(duì)了。

但是Google的提前注冊(cè)機(jī)制讓它能夠正確區(qū)分每一個(gè)藍(lán)牙產(chǎn)品，能夠應(yīng)對(duì) 更加復(fù)雜的環(huán)境。當(dāng)然，提前注冊(cè)機(jī)制對(duì)廠商和Google自身的要求就多了很多，可能導(dǎo)致GFP的使用范圍受限。