NHS COVID-19 接触者追踪应用的技术深度剖析

NHS COVID-19 接触者追踪测试版现已在 iOS 和 Android 上开源，同时还有一些文档。作为“保持存活”一文的后续，我们深入研究了源代码。令人惊喜的是，它采用 MIT 许可证，这表明 NHSX 致力于透明和质量。

在过去两天里，多名工程师一直在研究这款应用，想弄清它是否能够保持存活，以及如何做到。要理解这一点，需要比大多数开发者所掌握的更深入地了解相关的 CoreBluetooth 框架。这并不是工程师通常需要深入研究的框架。

很早的时候，我们就发现并报告了这个技巧在 Android 设备上是如何运作的。今晚，我们来分享 iOS 上究竟发生了什么。让我们一步步来看。

初次启动

首次启动时，应用会向 https://api.svc-covid19.nhs.uk/api/devices/registrations 发出一个 PUT 请求，其中包含激活码、推送通知令牌，以及用户输入的邮政编码的前半部分。服务器的响应是一个 linkingId，它会存储在应用的设置中。应用还会请求推送通知和蓝牙权限，这符合预期。它不会请求位置权限，因此也不会验证用户的邮政编码。只需要邮政编码的前几位数字。

有说法称 Android 应用会访问位置数据，因为 Android 设备上请求访问蓝牙 API 的提示似乎会要求位置权限。不过，我们昨天已经驳斥了这一点：这是 Android 管理蓝牙权限请求的方式所导致的结果。

在 Android 上保持存活

在 Android 上，防止应用在后台休眠很简单，因为原生 API 支持这一功能，让工程师可以对蓝牙硬件进行底层访问。

然而，在 iOS 上情况就没有这么简单了。当应用在 iOS 上退到后台时，其功能会大幅减少。CoreBluetooth 也是如此，这是 Apple 让开发者访问蓝牙的框架。除非有巧妙的变通办法，否则这会让应用检测可能运行在后台模式的 iPhone 变得困难得多。我们用多台 iOS 设备做了测试，让它们闲置了数小时，发现轮询的频率降低了，但这些设备在夜间仍然在通信。

用 Android 唤醒 iPhone

昨天我们还报告过，iOS 应用退到后台时，仍会继续广播蓝牙广告，只是采用了一种 Apple 特有的不同方式。我们认为 NHSX / Pivotal 的工程师对此进行了逆向工程，并为 Android 应用增加了对它的支持。我们可以确认事实正是如此，他们对此的技术细节可以在这里找到。这意味着，除了 iOS 设备能够让应用保持在后台之外，Android 设备还可以唤醒一台“沉睡”的 iOS 设备，无论它已经在后台多久。

那么，这意味着什么？意味着要让应用正常工作，iPhone 必须相当频繁地处于某台 Android 设备的范围之内，这样才能发送保活信号，让自己保持在后台。仅凭这一点，可能不是一个可行的方案，但是……

用 iOS 设备唤醒……其他 iOS 设备

在昨天的“保持存活”一文中，我们报告说，我们认为 iOS 应用使用“保活信号”来绕过后台限制。在检查了 iOS 应用的源代码之后，我们得出结论，情况确实如此。不过，它们究竟是如何工作的呢？

简单来说，在这里，保活信号是应用开发者想出来的一个办法：它是运行该应用的两台 iOS 设备之间发送的一种通知，用来保持两台设备之间的连接。有趣的是，这样做还有一个效果，就是让应用能够保持唤醒状态的时间明显更长，因为当设备收到保活信号时，iOS 会允许应用保持唤醒，以进行一些额外的处理。

从实际角度看，这意味着只要应用靠近其他设备，就能保持存活状态。从某种意义上说，这正是 COVID-19 追踪项目的初衷：即使没有这个技术技巧，也需要有足够多的用户运行追踪应用，才能取得良好的公共安全成果。

无论如何，应用在退到后台时不会立即进入休眠和挂起状态。因此，问题就变成了：大多数用户周围是否有足够多的 iOS 或 Android 设备，使这些变通办法可行。我们的看法是，这似乎很有可能，对于更经常出现在人口密集地区的用户来说更是如此。蓝牙的有效范围相当可观。

一些观察人士提出，应用能够接收静默通知，意味着它在利用这些能力远程唤醒自己。然而，这些能力只是用来告知用户，他们是否曾靠近感染过 COVID-19 的人。应用还使用了本地通知，用来检测应用何时被系统终止，并提示用户重新打开应用。当用户禁用蓝牙时，也会使用类似的通知。

Reincubate 的 CEO Aidan Fitzpatrick 表示：

没错，iOS 13.5 中即将推出的 Apple ExposureNotification 框架确实让这些保活信号变得不再必要。不过，值得注意的是：
iOS 13.5 尚未发布，可能还要几周
在昨天之前，iOS 13.5 的最新测试版存在严重的安全漏洞，说明 Apple 的工程团队正在进行大量艰巨的工作
发布之后，大多数 iOS 用户可能要数月才会完成安装（不同寻常的是，Android 上的对应升级可能会更快）
较旧的 iOS 设备，例如 iPhone 6，无法运行 iOS 13，也就无法使用 Apple 的方案
NHS COVID-19 应用没有理由不能在未来自动过渡到使用 Apple 的框架，甚至可以同时运行两种机制
随着越来越多的人使用，这款应用会变得越来越有效，从这个意义上说，大规模采用的好处会形成飞轮效应。澳大利亚的 COVIDSafe 应用举步维艰，因为它不支持从 Android 设备检测退到后台的 iOS 设备，也没有这种巧妙的 iOS 到 iOS 的保活机制。
有必要思考一下，在哪些情况下使用这样的技术是恰当的。如果接触者追踪成功地挽救了生命，那么在未来的疾病中是否应用它，应该依据哪些标准来评估？一旦开了先例，是否有理由认为这种技术可能被用来对抗已经存在的传染病？可以预见，不同的社会会以不同的方式权衡利弊。

隐私保障

虽然详细分析该协议背后的数学原理有点超出本文的范围，但我们确实查看了隐私保障措施。这款应用似乎严格遵守了 NCSC 发布的论文。我们可以确认，在用户报告症状之前，没有任何密钥数据会离开用户的设备，而且只有到那时，与其近距离接触过的设备的匿名密钥才会离开设备。用户输入的邮政编码的前半部分，会作为注册服务的一部分发送给 API。

归根结底，代码表明，在用户报告症状并联系 NHS 安排检测之前，使用这款应用几乎没有技术上的隐私风险。到那时，他们的检测结果将由 NHS 管理，不过这无论有没有这款应用都没有区别。然而，当多名用户发生接触、报告症状，并且使用应用提供给他们的标识符安排检测时，可能能够也可能无法在中央层面把他们关联起来。这是后端的问题，正如 NHSX 在其应用隐私报告中所说，在这方面，代码就是真相。