蘋果的創始人喬布斯曾經因為感到背叛，和谷歌的前董事長施密特勢不兩立。

而如今全人類面臨新冠病毒威脅，兩家一度不共戴天的公司走到了一起，共同開發了一套接觸者追蹤 (Contact Tracing) 技術。

因為它一定程度上可以起到流行病學追溯和感染風險警報的功能，這個技術也被昵稱為美國版“健康碼”。

但是健康碼和 Contact Tracing 在實現思路上也有很大的不同，前者更多依賴大數據，隱私風險頗高，后者主要基于藍牙，設計體現了對隱私保護的考慮。

今天硅星人帶你了解一下 Contact Tracing 的工作原理。

“三碼合一”，匿名追蹤

Contact Tracing 的工作原理大致如下：

設備之間通過低功耗藍牙 beacon 的方式，同時作為發送者和接受者，交換并保存彼此的信息。

當某人甲確診之后，甲的設備信息上傳到云端的一個確診者資料庫，所有的用戶都會每天從這個云端資料庫下載信息并在本地查驗。如果乙曾經收到過相同的信息，則可以認為乙是甲的接觸者。

當然，如果直接使用設備唯一識別信息，會有較大的隱私風險。所以出于隱私保護的目的，蘋果和谷歌費盡心機設計了一個“三碼合一”的機制。

為了方便更多讀者理解，我們簡單把這三碼分別簡稱為 A、B、C 碼。

首先，每臺用戶的手機都會生成一個固定不變的 A 碼，不會上傳;

通過 A 碼，手機可以每天生成一個 B 碼，平時不會上傳;

既然要實現接觸追蹤，所以手機需要每隔一段時間(API 建議的是15分鐘)對外廣播一次。此時廣播出來的是用 B 生成的 C 碼，每15分鐘/一個廣播周期內更新一次。平時只有這個 C 碼會被上傳。

由于這種 Contact Tracing 是通過 API 實現的，iOS 和 Android 設備都可以互相廣播和接收。

通過這種設計，蘋果和谷歌希望最大限度確保：

• 交換的信息本身是匿名化的;
• 即便滿足隱私保護的要求，在需要的時候仍可以對信息進行解密，定位到接觸者。

稍微詳細點的解釋：

• A 碼叫做 Tracing Key，在手機上首次啟動 Contact Tracing 時生成，長度為32字節，設備唯一，不會變化。雖然名字里有個“追蹤”，實際上 A 碼不會被上傳，只保存在手機上，也沒有識別作用，只是作為下一步計算 B、C碼時的輸入。

A 碼是一個隨機數，使用加密學隨機數生成器 (CRNG) 生成。

當你首次在自己的 iPhone 或者 Android 手機上使用其它政府、公司或機構基于蘋果谷歌方案開發的接觸追蹤軟件時，你的手機就會自動生成這樣隨機、唯一的 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天的記錄里，就完成了接觸者的追蹤和驗證。

蘋果和谷歌發布的 Contact Tracing 藍牙工作原理提供了一張圖片，闡釋這個過程：

優勢和劣勢

總的來說，這套技術實現方式最直接的優勢，就是在滿足功能的前提下最大限度保護用戶隱私。

在 Contact Tracing 加密和藍牙工作原理白皮書中，兩家公司指出，前兩種碼的生成周期是固定的，能夠避免其它應用獲取并用于無關的追蹤目的。

上傳的信息中不包括地理位置信息，嚴格僅限使用低功耗藍牙 beacon。

C 碼是和 B 碼綁定的，沒有 B 碼，獲得了 C 碼也沒有意義。

比方說某國政府用這套 API 開發了一個追蹤工具，管理員在服務器端也是無法了解到某健康用戶接觸了哪些其它用戶——管理員只可以對確診患者這樣做。

即使有確診患者出現，對其上傳的診斷碼的計算也只是在其它用戶的手機上進行，而非在服務器端。

由于設定了藍牙廣播和掃描間隔，以及每個 C 碼的長度只有16字節，這套技術實現方式也比較省電、省存儲空間。總體來看，它的電量消耗應該不會很可觀，至少不會達到夸張的成都。當然，具體的廣播和掃描間隔可以由追蹤工具的運營者自行設定，蘋果和谷歌也建議運營者考慮電量消耗。

蘋果和谷歌還在白皮書中告誡追蹤工具的運營者，不要從用戶的手機上提取其它無關的元數據。

這套技術實現方式也有一些劣勢。

其中最直接的劣勢，來自于藍牙本身的工作原理。

低功耗藍牙的最遠理論距離可以達到100米，而且也有一定的穿墻能力(隔一堵水泥墻往往沒什么問題，金屬的阻隔效果更強)。

這意味著如果你只是在空氣流動的戶外隔著幾十米“擦肩”了陌生人，或者明明和他分別處在兩個房間，只要你們的手機都裝了 Contact Tracing，都開了藍牙——只要那人被確診，你也有很大可能“不幸”成為接觸者。

另外，有人應該能看出來 Contact Tracing 是不完善的：就算發現并通知了接觸者，僅靠這個機制本身，無法定位到他。知道自己成為接觸者的，只有接觸者本人。接下來他是否愿意主動配合居家隔離，最終還是依賴于個人意志，權威機構很大程度上是無能為力的。

這些功能可能需要 app 開發者自行開發，但是這樣做的話也一定程度違背了 Contact Tracing 隱私保護設計的初衷。

針對這一點，蘋果和谷歌提供的說明書寫到，當接觸者收到通知之后接下來該怎么做，需要衛生部門的網站或 app 進一步說明。

另外也存在一種搗亂的可能性，就是故意生成并廣播大量的偽造的 C 碼。不過除了占據用戶手機的儲存空間之外，目前這種攻擊方式還沒有其它可見的危害。

當然，這還只是一個相對比較早期的技術，蘋果和谷歌也不是實際的實施者，具體使用的效果要看采用這套技術的政府或其它公司。

iOS 和 Android 的 API 已經發布在兩家公司的網站上。