谷歌和苹果发布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