【前言】當地時間2020年4月10日，蘋果與谷歌宣布將聯手推出一項方案，利用藍牙技術幫助政府和衛生機構減緩病毒蔓延，這項方案也被國內媒體解讀為歐美版「健康碼」。對於「健康碼」這個概念，相信在國內的大家已經很熟悉了，疫情期間成為了防控工作的一個有效工具。當歐美版這個「健康碼」新聞出來的時候，我們第一時間也關注到了這個新聞，第一反應是美國的網際網路公司終於「抄作業」了。不過從我們對蘋果和谷歌的技術細節進行深入了解之後，我們發現這個歐美版的「健康碼」並不是直接抄作業，而是根據歐美國家的國情做了很不一樣的設計，本文也將通過分析這項技術方案的設計原則來講解歐美版的「健康碼」到底哪裡不一樣。
筆者註：本文的技術分析基於蘋果和谷歌官方技術文檔，以及開源項目。DP-3T （Decentralized Privacy-Preserving Proximity Tracing）開源項目跟蘋果和谷歌沒有直接聯繫，DP-3T是由一群歐洲的科學家所發起的疫情追蹤開放式協議，不過DP-3T所倡導的大部分設計思想已被蘋果和谷歌採納，因此本文的大部分內容都來源於DP-3T開源項目的白皮書。
國內版「健康碼」
首先讓我們來看看國內目前健康碼大體的一個技術架構。根據我們對所見到的健康碼分析研究，我們認為國內健康碼大多採取的是中心化的大數據收集和分析模式，其具備以下幾個特點：
·中心化存儲所有用戶的行程和身份信息，方便統一進行大數據分析和調控。
·沒有確診的用戶數據也會上傳，確保出現疫情的時候能夠快速通知到密切接觸人群。
·收集的用戶信息包含了身份信息，行程信息等敏感數據，方便進行數據關聯分析。
·數據生命周期不太明確，超過一定天數的數據是否刪除掉沒有統一標準。
基於以上幾個特點，國內的健康碼實行起來可以達到高效快速甄別密切接觸人群的目的，不過一定程度上用戶數據的隱私沒有徹底的保護，數據被濫用的可能性也存在。那麼，讓我們看看國外是怎麼設計的吧。
歐美版「健康碼」
設計目標
由於歐美國家的對於數據隱私保護上有很強的監管，因此在設計疫情監控方案的時候，需要充分考慮到數據隱私保護的影響。同時，歐美民眾天然對政府和大型企業缺乏信任，過度中心化的架構在做疫情監控上也會有不少主力，因此谷歌和蘋果在提出他們的疫情監控方案時候，在同時滿足能夠快速確定密切接觸人群的同時，需要滿足一下幾點數據隱私保護要求：
·最小化收集的數據量。疾控部門應該儘可能的減少對數據收集的要求，同時確保數據匿名化，也就是脫敏。數據只保留能夠快速追蹤密切接觸人群的最必要部分，任何機構都沒法從這個數據裡面獲取敏感個人信息。
·不上傳沒有確診用戶數據。用戶在沒有確診的時候，在沒有徵得用戶授權之前，數據不能上傳到疾控部門那裡，數據會一直留在用戶自己的手機裡面。
·過期數據定期刪除。所有數據應該有一個固定的過期時間，超過這個時間數據應該刪除，進一步降低數據洩露的風險。
·儘可能杜絕數據濫用。因為收集的數據量是極少的，而且在發送給後端之前已經進行了匿名化處理，數據被大規模濫用的可能性也會降到最低。
基於上述數據隱私保護要求，我們來看看歐美版的「健康碼」，是如何具體設計的。
技術細節
簡單來講，歐美版的「健康碼」採用藍牙的BLE（Bluetooth Low Energy）廣播技術，這項技術可以讓設備通過低功耗藍牙協議，向周圍的近距離其他藍牙設備進行廣播信息。由於目前智慧型手機基本具備藍牙功能，因此這個技術方案設計了一個在近距離接觸其他設備時候的信息收集方式，讓我們來看看是他們怎麼做的。
首先，每個設備都需要生成Ephemeral IDs（臨時身份標示符）。EphID生成是依賴某種密碼學算法，因此需要一個私鑰SK。這個私鑰為了確保安全，是需要每天進行更換，當天的私鑰是根據前一天的私鑰的某種哈希值而生成：
另外為了進一步確保EphID的匿名性，該設計要求每天需要生成若干個新的EphIDs，根據相應的時間間隔進行輪換。這個輪換的時間間隔是可以按照分鐘進行配置，假如是30分鐘，那麼每天需要生成48個EphIDs以供輪換。生成EphIDs的算法如下：
PRF是個偽隨機函數（例如：HMAC-SHA256），「broadcast key」是個固定公開的字符串，PRG是一個流加密函數（例如：AES CTR模式）產生n個16 bytes的EphIDs。然後設備可以將這個生成的n個EphIDs隨機打亂順序，然後依次進行使用。這些生成的EphIDs都會存在設備本地，以供後續使用。
當設備有了這些EphID來表示自己的身份之後，會在設備開啟過程中持續向周圍安裝了同樣服務的設備廣播自己的EphID，因此這些設備在運行過程中都會存儲除了自己的 EphID之外的，收到的其他人的EphID，以及一些包含了收到時間的輔助信息。這些設備本地會有一個數據過期時間的配置，例如14天，超過這個時間窗口的數據會被自動清除。我們可以算出來，如果一個人每天接觸100個人，每個人每天有100個EphIDs，14天窗口內，可能需要存儲140k個EphID，EphID的存儲代價是32bytes，因此總體數據量是 4.2 MB，這是一個非常小的數據量了。
那麼，當一個患者確診之後的流程又是怎樣的呢，我們可以參考上圖：
1.患者主動或者被動（根據所在國政策）上傳具有傳染性第一天的私鑰信息到後端伺服器。這個後端伺服器可以是網際網路公司的雲，也可以是政府機構的機房。
2.後端伺服器在收到信息之後會廣播確診患者的私鑰信息，給所有使用該伺服器的設備。這種廣播可以是通過推送的方式進行，也可以是手機設備通過定期輪詢抓取的方式進行。
3.手機收到相關患者私鑰信息之後，會在本地進行一些計算，以確認感染風險，如果感染風險高於閾值，會觸發手機報警。
4.對於高於風險閾值的密切接觸者，可以選擇將自己與患者的接觸信息，包括次數，相對時間等脫敏後的匿名數據，上傳給疾控部門或者流行病學家。這種上傳可以是定期批量上傳，以節省手機的資源消耗。當然很重要的一點是，用戶也可以選擇不上傳。
5.確診患者在確保已完成私鑰上傳之後，需要重新隨機生成一個全新的私鑰，這樣的話確保之後的隱私不會被侵犯。
根據以上的確診患者的數據上報流程，我們可以總結這套設計方案有以下幾個特點：
·後端伺服器扮演的是一個通信媒介的作用，本身不做大規模的數據存儲和分析。這樣就算是後端伺服器被黑或者被濫用，也可以將隱私洩露的風險降到最低。
·對於是否要分享自己的信息給疾控中心相關人員，用戶有自己的選擇權。對於不想共享這部分數據的用戶，可以在自己的手機上關閉。
·疾控中心收到的所有用戶分享的數據全部匿名化脫敏處理，而且數據量非常有限。因此無法從收到的數據裡面探知具體的位置信息，真實身份信息等等。
兩種「健康碼」比較
從上面我們對於兩種「健康碼」技術架構的分析來看，歐美版的「健康碼」在隱私保護上的確有下足功夫，具體可以表現為以下幾個優勢：
·數據收集量很小，每個人每天的數據量<1MB。
·無敏感數據收集，數據匿名化處理，用密碼學方法保證隱私性。
·超過一定時間的數據會被清除。
·未確診患者數據無需上傳，用戶在數據上傳上有選擇權。
·去中心化架構為主，中心化伺服器只作為通信媒介。
不過，從我們對實際運行情況了解來看，這套方案在現實推廣中也會遇到不少問題，總結來說我們認為會有以下幾個劣勢：
·設備如果未開啟藍牙、藍牙功能缺失或者遇到手機沒有電，這部分工作就完全無法進行。
·藍牙傳輸協議的安全性有待商榷，已知已有多種針對藍牙傳輸協議的安全攻擊。
·在人口密集區域，這套廣播協議對設備電量損耗和實際傳輸成功效率都會有不少影響。
·如果很大一部分用戶不積極主動上傳數據給疾控部門，疫情防控工作效率會大打折扣。
·如果被不懷好意的人利用這套協議惡意提交錯誤數據，比如提交錯誤的接觸數據等，會造成一定程度的錯誤判斷。
所以，具體運行過程中這套協議是否能夠有效，非常取決於所在地的國情，我們將繼續觀察這套技術協議在落地過程中的情況。
總結
本篇文章，我們介紹最近推出的歐美版「健康碼」的技術架構和一些細節。我們可以看到國外的模式非常注重隱私和去中心化，這點值得學習。不過這套技術方案是否真正可行和效率高，還需要實際運行檢驗，我們希望在國外技術公司和政府部門努力下，這套模式能有個好的最終落地結果。（作者：方建，續科天下（北京）科技有限公司CTO）