Apple的創始人賈伯斯曾經因為感到背叛，和Google的前董事長施密特勢不兩立。而如今全人類面臨新冠病毒威脅，兩家一度不共戴天的公司走到了一起，共同開發了一套接觸者追蹤（Contact Tracing）技術。主要基於藍牙，設計體現了對隱私保護的考慮。今天我們來了解一下Contact Tracing 的工作原理。
👉 歡迎加入T客邦telegram ( https://t.me/TechbangNEWS )
Contact Tracing 的工作原理大致如下：
設備之間透過低功耗藍牙beacon 的方式，同時作為發送者和接受者，交換並保存彼此的訊息。
當某人甲確診之後，甲的設備訊息上傳到雲端的一個確診者資料庫，所有的使用者都會每天從這個雲端資料庫下載訊息並在本地查驗。如果乙曾經收到過相同的訊息，則可以認為乙是甲的接觸者。
當然，如果直接使用設備唯一辨識訊息，會有較大的隱私風險。所以出於隱私保護的目的，Apple和Google費盡心機設計了一個「三碼合一」的機制。
為了方便更多讀者理解，我們簡單把這三碼分別簡稱為A碼（Tracing Key）、B碼（Daily Tracing Key）、C碼（Rolling proximity Identifier）。
- 首先，每台使用者的手機都會產生一個固定不變的A 碼，不會上傳；
- 透過A 碼，手機可以每天產生一個B 碼，平時不會上傳；
- 既然要做到接觸追蹤，所以手機需要每隔一段時間（API 建議的是15分鐘）對外廣播一次。此時廣播出來的是用B碼來產生的C碼，每15分鐘/一個廣播週期內更新一次。平時只有這個C碼會被上傳。
由於這種Contact Tracing 是透過API 完成的，iOS 和Android 設備都可以互相廣播和接收。
透過這種設計，Apple和Google希望最大限度確保：
- 交換的訊息本身是匿名化的；
- 即便滿足隱私保護的要求，在需要的時候仍可以對訊息進行解密，定位到接觸者。
稍微詳細點的解釋：
A碼叫做Tracing Key，在手機上首次啟動Contact Tracing時產生，長度為32字節，設備唯一，不會變化。雖然名字裡有個「追蹤」，實際上A碼不會被上傳，只保存在手機上，也沒有辨識作用，只是作為下一步運算B、C碼時的輸入。
A碼是一個隨機數，使用加密學隨機數產生器（CRNG） 產生。
當你首次在自己的iPhone 或者Android 手機上使用其它政府、公司或機構基於AppleGoogle方案開發的接觸追蹤軟體時，你的手機就會自動產生這樣隨機、唯一的A碼。
這個碼和你手機的已知辨識碼，比如序列號、mac地址，都沒有關係，而且不會上傳，所以幾乎不存在隱私風險。
B碼叫做Daily Tracing Key，是從A碼使用HKDF函數派生而來的，長度為16個字節。每24小時更新一次，
B碼沒事的時候也不會上傳。它平時的主要作用是作為輸入，產生C碼。只在確診時，B碼才會派上用場。如果使用者健康且沒有接觸風險，B碼也是永遠保存在手機上的，不會上傳。
假設使用者甲在過去幾天內和確診的乙發生過接觸，存在感染的風險，甲在這幾天裡的B碼就會被作為「診斷碼「（Diagnostic Keys），被提取用於確認身份。B碼只在此時才會被提取走。總的來說，不管怎樣，B 碼都不會被預設（自動）上傳。
上傳的C碼又是什麼呢？
C碼叫做Rolling Proximity Identifier，是對B碼進一步進行加密產生的消息認證碼（HMAC），長度為16個字節，透過低功耗藍牙每15分鐘對周圍的所有設備廣播一次，安裝了Contact Tracing的手機可以接收到並保存這個碼。
為了保護隱私避免追蹤，從藍牙4.2版本開始設備的藍牙MAC地址可以隨機變化。順應了這一點，Contact Tracing 會在每次藍牙MAC地址改變的時候，產生一個新的C碼。
除了廣播出去之外，手機還會保存在過去一段時間內產生的所有C碼，用於在追蹤接觸者時進行校驗。
如何追蹤接觸者？
如果你理解了前一節，那麼這裡就更好理解了。
我們假設甲確診了，比如追溯期是14天內，就用甲手機在過去14天裡的B碼作為「診斷碼」，上傳到雲端。
所有使用者的手機每天都會從伺服器下載一次所有的確診患者的診斷碼，然後在本地採用和運算C碼一樣的加密演算法算一遍。
我們假設過去14天裡甲和乙曾經共處一室一段時間，那麼乙的手機上一定保存了來自甲的C碼。如果乙的手機經過計算，得到的C碼出現在自己保存的過去14天的記錄裡，就完成了接觸者的追蹤和驗證。
Apple和Google發布的Contact Tracing 藍牙工作原理提供了一張圖片，闡釋這個過程：
優勢和劣勢
總的來說，這套技術實現方式最直接的優勢，就是在滿足功能的前提下最大限度保護使用者隱私。
在Contact Tracing 加密和藍牙工作原理白皮書中，兩家公司指出，前兩種碼的產生周期是固定的，能夠避免其它應用獲取並用於無關的追蹤目的。
上傳的訊息中不包括地理位置訊息，嚴格僅限使用低功耗藍牙beacon。
C碼是和B碼綁定的，沒有B碼，獲得了C碼也沒有意義。
比方說某國政府用這套API 開發了一個追蹤工具，管理員在伺服器端也是無法了解到某健康使用者接觸了哪些其它使用者——管理員只可以對確診患者這樣做。
即使有確診患者出現，對其上傳的診斷碼的計算也只是在其它使用者的手機上進行，而非在伺服器端。
由於設定了藍牙廣播和掃描間隔，以及每個C碼的長度只有16字節，這套技術實現方式也比較省電、省存儲空間。總體來看，它的電量消耗應該不會很可觀，至少不會達到誇張的成都。當然，具體的廣播和掃描間隔可以由追蹤工具的運營者自行設定，Apple和Google也建議運營者考慮電量消耗。
Apple和Google還在白皮書中告誡追蹤工具的運營者，不要從使用者的手機上提取其它無關的元數據。
這套技術實現方式也有一些劣勢。
其中最直接的劣勢，來自於藍牙本身的工作原理。
低功耗藍牙的最遠理論距離可以達到100公尺，而且也有一定的穿牆能力（隔一堵水泥牆往往沒什麼問題，金屬的阻隔效果更強）。
這意味著如果你只是在空氣流動的戶外隔著幾十公尺「擦肩」了陌生人，或者明明和他分別處在兩個房間，只要你們的手機都裝了Contact Tracing，都開了藍牙— —只要那人被確診，你也有很大可能「不幸」成為接觸者。
另外，有人應該能看出來Contact Tracing是不完善的：就算發現並通知了接觸者，僅靠這個機制本身，無法定位到他。知道自己成為接觸者的，只有接觸者本人。接下來他是否願意主動配合居家隔離，最終還是依賴於個人意志，權威機構很大程度上是無能為力的。
這些功能可能需要 app 開發者自行開發，但是這樣做的話也一定程度違背了Contact Tracing 隱私保護設計的初衷。
針對這一點，Apple和Google提供的說明書寫到，當接觸者收到通知之後接下來該怎麼做，需要衛生部門的網站或app 進一步說明。
另外也存在一種搗亂的可能性，就是故意產生並廣播大量的偽造的C碼。不過除了佔據使用者手機的儲存空間之外，目前這種攻擊方式還沒有其它可見的危害。
當然，這還只是一個相對比較早期的技術，Apple和Google也不是實際的實施者，具體使用的效果要看採用這套技術的政府或其它公司。
👉 歡迎加入T客邦telegram ( https://t.me/TechbangNEWS )
- 本文授權轉載自Pingwest
請注意！留言要自負法律責任，相關案例層出不窮，請慎重發文！