NHS COVID-19联系人跟踪应用程序的技术深入探讨

现在，NHS COVID-19联系人跟踪beta和一些文档对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支持此功能，从而使工程师可以低级访问Bluetooth硬件。

但是，在iOS上，故事还不那么简单。当应用在iOS上后台运行时，其功能将大大降低。 Apple框架CoreBluetooth 也是如此 ，该框架为开发人员提供了访问蓝牙的权限。缺乏巧妙的解决方法，这使得应用程序很难检测到可能在后台模式下运行的iPhone。我们在几个小时的过程中对许多单独放置的iOS设备进行了测试，并注意到轮询发生的频率降低了，但这些设备仍然通宵交流。

使用Android唤醒iPhone

昨天我们还报告说，在后台运行时，iOS应用程序继续广播蓝牙广告，但是以苹果特有的不同方式。我们相信NHSX / Pivotal工程师对此进行了反向工程，并为Android应用程序添加了支持。我们可以确认是这种情况，可以在此处找到有关其的技术详细信息。这意味着，除了iOS设备可以使应用程序处于后台运行状态之外，Android设备还可以唤醒处于“休眠状态”的iOS设备，而无需考虑后台运行了多长时间。

那么这意味着什么呢？好吧，这意味着要使该应用程序正常运行，iPhone必须经常位于Android设备的范围内，以便它可以发送keepalive使其保持背景。单靠这可能不是一个可行的解决方案，但是...

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

在昨天的“ 保持生命 ”帖子中，我们报告说我们认为iOS应用正在使用“ keepalives”来规避背景限制。在检查了iOS应用程序源代码后，我们得出结论确实如此。但是，它们如何工作？

简而言之，在这种情况下，keepalive是应用程序开发人员想出的一个主意：这是在两个运行该应用程序的iOS设备之间发送的通知，以保持设备之间的连接保持活动状态。有趣的是，它还具有使应用程序保持清醒状态的时间更长的效果，因为当设备接收到保持活动状态时，iOS允许应用程序保持清醒状态以执行一些其他处理。

从实际角度看，这意味着该应用程序在与其他设备相邻的情况下将能够维持其活动状态。从某种意义上讲，这就是COVID-19跟踪项目的基本原理：即使没有此技术诀窍，也需要大量用户运行跟踪应用程序才能获得良好的公共安全结果。

无论如何，应用程序在后台运行时都不会立即入睡并进入暂停状态。因此，问题就变成了大多数用户是否会在足够的iOS或Android设备周围使用该变通办法。我们认为这似乎是可能的，对于经常居住在人口稠密地区的用户而言，更是如此。蓝牙具有不错的有效范围。

一些观察者认为，该应用程序具有接收静默通知的功能，意味着它正在使用这些功能远程唤醒自身。但是，这些功能仅用于通知用户他们是否靠近签有COVID-19的任何人。该应用程序还利用本地通知来检测应用程序何时被系统杀死，指示用户重新打开该应用程序。当用户禁用蓝牙时，会使用类似的通知。

Reincubate的首席执行官Aidan Fitzpatrick说：

是的，在这种情况下，iOS 13.5中即将发布的Apple ExposureNotification框架消除了对这些keepalive的需求。但是，值得注意的是：

• iOS 13.5尚未发布，可能已经有几个星期了
• 昨日之前，最新的iOS 13.5 beta版存在一个重大安全漏洞 ，这表明Apple的工程团队正在进行繁重的工作
• 一旦发布，大多数iOS用户可能会花费数月的时间来安装它（通常，同等的Android应用可能会更快 ）。
• 较旧的iOS设备（例如iPhone 6）无法运行iOS 13，并且将无法使用Apple技术
• 没有理由为什么NHS COVID-19应用程序将来无法自动过渡到使用Apple的框架-甚至双重运行这两种机制

随着更多人使用它，该应用将变得越来越有效，而大规模采用的好处将在这种意义上产生飞轮效应。澳大利亚的COVIDSafe应用程序苦苦挣扎，因为它不支持从Android设备中检测后台的iOS设备，并且它没有这种聪明的iOS到iOS保持活动机制。

重要的是要反思在什么情况下可以使用这种技术。如果成功地进行了接触者追踪挽救生命，应评估哪种标准是否适用于将来的疾病？一旦确立了先例，是否有论点认为该技术可用于对抗已有的传染病？可以预见，不同的社会会对折衷方案进行不同的评估。

隐私保护

虽然撰写该协议背后的数学方法的详细分析超出了本文的讨论范围，但我们确实研究了隐私保护措施。该应用程序似乎严格遵守NCSC发布的论文 。我们可以确认在用户报告症状之前，没有密钥数据离开用户的设备，只有这样，该设备附近的设备的匿名密钥才能离开该设备。用户输入的邮政编码的前半部分将作为注册服务的一部分发送到API。

最终，该代码表明，直到用户报告症状并联系NHS安排测试之前，使用该应用程序几乎不会带来技术隐私风险。到那时，他们的测试结果将由NHS进行管理，尽管使用或不使用该应用程序都没有什么不同。但是，当多个用户联系，报告症状并 使用应用程序已提供给他们的标识符安排测试时，可能或不可能将他们集中在一起。这是一个后端问题，正如NHSX在其应用程序隐私报告中所述， 代码在这方面是真理 。

防止虚假报告

由于系统的后端尚未开放源代码，因此无法确认，但似乎直到市民对COVID-19测试为阳性之前，没有推送通知发送到其他设备。用户报告症状后，将获得可用于预订测试的参考代码。 （此代码与我们在注册部分中描述的linkingId相同。）