谷歌和苹果发布 Exposure Notification API 草案

几周前，谷歌和苹果宣布，他们将联合在移动操作系统上为接触者跟踪应用程序提供可靠的支持。现在，这一合作达到了一个关键的里程碑：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中提供，感兴趣的开发者可以试着开始接触者跟踪的实验了。

原文链接：

Google and Apple Publish Exposure Notification API Draft