幾周前，谷歌和蘋果宣佈，他們將聯合在移動操作系統上爲接觸者跟蹤應用程序提供可靠的支持。現在，這一合作達到了一個關鍵的里程碑：Exposure Notification API的初步草案及其iOS測試版。
需要說明的是，蘋果和谷歌已經將他們的技術解決方案重新命名爲暴露通知（exposure notification），這比接觸者跟蹤（contact tracing）好。重新命名的原因是，接觸者跟蹤是一種更廣泛的解決方案，會涉及到某種集中式系統，用戶可以連接到上面，而這應該由區域衛生當局提供。蘋果和谷歌只是爲這類應用程序提供技術基礎，因此這個名稱更合適。
爲了加強隱私，新API考慮了由谷歌和蘋果定義的加密協議的顯著變化。最初，該協議使用了兩個加密密鑰，一個用戶唯一的Tracing Key，永遠不會離開設備，另一個是Daily Tracing Key，它是基於前者生成的一個跟蹤密鑰。Daily Tracing Keys用於生成Rolling Proximity Identifiers（又稱僞隨機藍牙標識符），用於檢測特定的時間段內設備的鄰近性。
實際上，當設備可以直接訪問時，有一個與其相關聯的唯一密鑰會打開高級攻擊的大門。因此，新版本的協議使用完全隨機的Temporary Exposure Keys來生成Rolling Proximity Identifier Keys，然後再用它們生成Rolling Proximity Identifier。按照蘋果和谷歌的說法，由於Rolling Proximity Identifier不是由一個生存期爲24小時的完全隨機的密鑰生成的，所以在不知道相應的Temporary Exposure Keys的情況下，攻擊者在Rolling Proximity Identifier上找到碰撞攻擊的機會在計算上是不可行的。這減少了重播攻擊和僞裝攻擊的機會。
新的Exposure Notification框架包含兩個用戶角色：*受影響的用戶（affected users）*和暴露的用戶（exposed users）。受影響的用戶是COVID-19的確診或疑似病例，而暴露的用戶可能與前者有過接觸。當用戶被確診時，他們的Temporary Exposure Keys將通過外部診斷服務器與其他可能暴露的用戶共享。此步驟需要用戶顯式授權。暴露的用戶可以使用ENSelfExposureInfoRequest檢索一組Temporary Exposure Keys，並請求框架使用ENExposureDetectionSession確定本地是否檢測到了這些密鑰。
Exposure Notification框架的核心類是ENManager，它負責一些準備任務，比如檢查App的授權狀態。ENManager可以使用其setExposureNotificationEnabled:completionHandler方法啓用暴露通知，在請求使用授權後啓動或停止藍牙廣播和掃描。在任何時候，都可以使用getDiagnosisKeysWithCompletionHandler:completionHandler來檢索此設備使用的Temporary Exposure Keys，並與診斷服務器共享。此步驟也需要顯式授權。
ENExposureDetectionSession類是和ENManager配對的類，因爲它可以檢查從診斷服務器接收到的Temporary Exposure Keys是否被檢測到了。這可以使用addDiagnosisKeys:completion和finishedDiagnosisKeysWithCompletion:方法來完成。如果檢測到用戶暴露過，則可以使用getExposureInfoWithMaxCount:completionHandler檢索更多信息，如接觸時長和日期。
瞭解更多關於新API的細節，請查閱Exposure Notification框架官方文檔。
新的Exposure Notification API剛剛在iOS 13.5開發者版本Beta 3中提供，感興趣的開發者可以試着開始接觸者跟蹤的實驗了。
原文鏈接：