蘋果的創(chuàng)始人喬布斯曾經(jīng)因?yàn)楦械奖撑?，和谷歌的前董事長(zhǎng)施密特勢(shì)不兩立。

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

因?yàn)樗欢ǔ潭壬峡梢云鸬搅餍胁W(xué)追溯和感染風(fēng)險(xiǎn)警報(bào)的功能，這個(gè)技術(shù)也被昵稱為美國(guó)版“健康碼”。

但是健康碼和 Contact Tracing 在實(shí)現(xiàn)思路上也有很大的不同，前者更多依賴大數(shù)據(jù)，隱私風(fēng)險(xiǎn)頗高，后者主要基于藍(lán)牙，設(shè)計(jì)體現(xiàn)了對(duì)隱私保護(hù)的考慮。

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

“三碼合一”，匿名追蹤

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

設(shè)備之間通過(guò)低功耗藍(lán)牙 beacon 的方式，同時(shí)作為發(fā)送者和接受者，交換并保存彼此的信息。

當(dāng)某人甲確診之后，甲的設(shè)備信息上傳到云端的一個(gè)確診者資料庫(kù)，所有的用戶都會(huì)每天從這個(gè)云端資料庫(kù)下載信息并在本地查驗(yàn)。如果乙曾經(jīng)收到過(guò)相同的信息，則可以認(rèn)為乙是甲的接觸者。

當(dāng)然，如果直接使用設(shè)備唯一識(shí)別信息，會(huì)有較大的隱私風(fēng)險(xiǎn)。所以出于隱私保護(hù)的目的，蘋果和谷歌費(fèi)盡心機(jī)設(shè)計(jì)了一個(gè)“三碼合一”的機(jī)制。

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

首先，每臺(tái)用戶的手機(jī)都會(huì)生成一個(gè)固定不變的 A 碼，不會(huì)上傳;

通過(guò) A 碼，手機(jī)可以每天生成一個(gè) B 碼，平時(shí)不會(huì)上傳;

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

由于這種 Contact Tracing 是通過(guò) API 實(shí)現(xiàn)的，iOS 和 Android 設(shè)備都可以互相廣播和接收。

通過(guò)這種設(shè)計(jì)，蘋果和谷歌希望最大限度確保：

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

稍微詳細(xì)點(diǎn)的解釋：

• A 碼叫做 Tracing Key，在手機(jī)上首次啟動(dòng) Contact Tracing 時(shí)生成，長(zhǎng)度為32字節(jié)，設(shè)備唯一，不會(huì)變化。雖然名字里有個(gè)“追蹤”，實(shí)際上 A 碼不會(huì)被上傳，只保存在手機(jī)上，也沒(méi)有識(shí)別作用，只是作為下一步計(jì)算 B、C碼時(shí)的輸入。

A 碼是一個(gè)隨機(jī)數(shù)，使用加密學(xué)隨機(jī)數(shù)生成器 (CRNG) 生成。

當(dāng)你首次在自己的 iPhone 或者 Android 手機(jī)上使用其它政府、公司或機(jī)構(gòu)基于蘋果谷歌方案開(kāi)發(fā)的接觸追蹤軟件時(shí)，你的手機(jī)就會(huì)自動(dòng)生成這樣隨機(jī)、唯一的 A 碼。

這個(gè)碼和你手機(jī)的已知識(shí)別碼，比如序列號(hào)、mac地址，都沒(méi)有關(guān)系，而且不會(huì)上傳，所以幾乎不存在隱私風(fēng)險(xiǎn)。

B 碼叫做 Daily Tracing Key，是從 A 碼使用 HKDF 函數(shù)派生而來(lái)的，長(zhǎng)度為16個(gè)字節(jié)。每24小時(shí)更新一次，

B 碼沒(méi)事的時(shí)候也不會(huì)上傳。它平時(shí)的主要作用是作為輸入，生成 C 碼。只在確診時(shí)，B 碼才會(huì)派上用場(chǎng)。如果用戶健康且沒(méi)有接觸風(fēng)險(xiǎn)，B 碼也是永遠(yuǎn)保存在手機(jī)上的，不會(huì)上傳。

假設(shè)用戶甲在過(guò)去幾天內(nèi)和確診的乙發(fā)生過(guò)接觸，存在感染的風(fēng)險(xiǎn)，甲在這幾天里的 B 碼就會(huì)被作為“診斷碼“(Diagnostic Keys)，被提取用于確認(rèn)身份。B 碼只在此時(shí)才會(huì)被提取走?？偟膩?lái)說(shuō)，不管怎樣，B 碼都不會(huì)被默認(rèn)(自動(dòng))上傳。

上傳的 C 碼又是什么呢?

C 碼叫做 Rolling Proximity Identifier，是對(duì) B 碼進(jìn)一步進(jìn)行加密生成的消息認(rèn)證碼 (HMAC)，長(zhǎng)度為16個(gè)字節(jié)，通過(guò)低功耗藍(lán)牙每15分鐘對(duì)周圍的所有設(shè)備廣播一次，安裝了 Contact Tracing 的手機(jī)可以接收到并保存這個(gè)碼。

為了保護(hù)隱私避免追蹤，從藍(lán)牙4.2版本開(kāi)始設(shè)備的藍(lán)牙MAC地址可以隨機(jī)變化。順應(yīng)了這一點(diǎn)，Contact Tracing 會(huì)在每次藍(lán)牙MAC地址改變的時(shí)候，生成一個(gè)新的 C 碼。

除了廣播出去之外，手機(jī)還會(huì)保存在過(guò)去一段時(shí)間內(nèi)生成的所有 C 碼，用于在追蹤接觸者時(shí)進(jìn)行校驗(yàn)。

如何追蹤接觸者?

如果你理解了前一節(jié)，那么這里就更好理解了。

我們假設(shè)甲確診了，比如追溯期是14天內(nèi)，就用甲手機(jī)在過(guò)去14天里的 B 碼作為“診斷碼”，上傳到云端。

所有用戶的手機(jī)每天都會(huì)從服務(wù)器下載一次所有的確診患者的診斷碼，然后在本地采用和計(jì)算 C 碼一樣的加密算法算一遍。

我們假設(shè)過(guò)去14天里甲和乙曾經(jīng)共處一室一段時(shí)間，那么乙的手機(jī)上肯定保存了來(lái)自甲的 C 碼。如果乙的手機(jī)經(jīng)過(guò)計(jì)算，得到的 C 碼出現(xiàn)在自己保存的過(guò)去14天的記錄里，就完成了接觸者的追蹤和驗(yàn)證。

蘋果和谷歌發(fā)布的 Contact Tracing 藍(lán)牙工作原理提供了一張圖片，闡釋這個(gè)過(guò)程：

優(yōu)勢(shì)和劣勢(shì)

總的來(lái)說(shuō)，這套技術(shù)實(shí)現(xiàn)方式最直接的優(yōu)勢(shì)，就是在滿足功能的前提下最大限度保護(hù)用戶隱私。

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

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

C 碼是和 B 碼綁定的，沒(méi)有 B 碼，獲得了 C 碼也沒(méi)有意義。

比方說(shuō)某國(guó)政府用這套 API 開(kāi)發(fā)了一個(gè)追蹤工具，管理員在服務(wù)器端也是無(wú)法了解到某健康用戶接觸了哪些其它用戶——管理員只可以對(duì)確診患者這樣做。

即使有確診患者出現(xiàn)，對(duì)其上傳的診斷碼的計(jì)算也只是在其它用戶的手機(jī)上進(jìn)行，而非在服務(wù)器端。

由于設(shè)定了藍(lán)牙廣播和掃描間隔，以及每個(gè) C 碼的長(zhǎng)度只有16字節(jié)，這套技術(shù)實(shí)現(xiàn)方式也比較省電、省存儲(chǔ)空間?？傮w來(lái)看，它的電量消耗應(yīng)該不會(huì)很可觀，至少不會(huì)達(dá)到夸張的成都。當(dāng)然，具體的廣播和掃描間隔可以由追蹤工具的運(yùn)營(yíng)者自行設(shè)定，蘋果和谷歌也建議運(yùn)營(yíng)者考慮電量消耗。

蘋果和谷歌還在白皮書中告誡追蹤工具的運(yùn)營(yíng)者，不要從用戶的手機(jī)上提取其它無(wú)關(guān)的元數(shù)據(jù)。

這套技術(shù)實(shí)現(xiàn)方式也有一些劣勢(shì)。

其中最直接的劣勢(shì)，來(lái)自于藍(lán)牙本身的工作原理。

低功耗藍(lán)牙的最遠(yuǎn)理論距離可以達(dá)到100米，而且也有一定的穿墻能力(隔一堵水泥墻往往沒(méi)什么問(wèn)題，金屬的阻隔效果更強(qiáng))。

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

另外，有人應(yīng)該能看出來(lái) Contact Tracing 是不完善的：就算發(fā)現(xiàn)并通知了接觸者，僅靠這個(gè)機(jī)制本身，無(wú)法定位到他。知道自己成為接觸者的，只有接觸者本人。接下來(lái)他是否愿意主動(dòng)配合居家隔離，最終還是依賴于個(gè)人意志，權(quán)威機(jī)構(gòu)很大程度上是無(wú)能為力的。

這些功能可能需要 app 開(kāi)發(fā)者自行開(kāi)發(fā)，但是這樣做的話也一定程度違背了 Contact Tracing 隱私保護(hù)設(shè)計(jì)的初衷。

針對(duì)這一點(diǎn)，蘋果和谷歌提供的說(shuō)明書寫到，當(dāng)接觸者收到通知之后接下來(lái)該怎么做，需要衛(wèi)生部門的網(wǎng)站或 app 進(jìn)一步說(shuō)明。

另外也存在一種搗亂的可能性，就是故意生成并廣播大量的偽造的 C 碼。不過(guò)除了占據(jù)用戶手機(jī)的儲(chǔ)存空間之外，目前這種攻擊方式還沒(méi)有其它可見(jiàn)的危害。

當(dāng)然，這還只是一個(gè)相對(duì)比較早期的技術(shù)，蘋果和谷歌也不是實(shí)際的實(shí)施者，具體使用的效果要看采用這套技術(shù)的政府或其它公司。

iOS 和 Android 的 API 已經(jīng)發(fā)布在兩家公司的網(wǎng)站上。