LWN：开源的密切接触者追踪方案（第一部分）
关注了就能看到更多这么棒的文章哦～
Open-source contact tracing, part 1
June 24, 2020
This article was contributed by Marta Rybczyńska
原文来自：https://lwn.net/Articles/823532/
主译：DeepL
应对COVID-19 疫情传播的措施之一就是找出接触过感染者的人，以便让他们能够了解风险，从而可以在有需要时寻找医疗服务。如果是人工统计的话，这会是一项繁重的工作。因此人们开发了一些应用程序来帮助追踪接触者。但是，有不少人担心这些应用程序是否有效，以及对隐私权的影响。许多应用程序都是在开源许可下发布的。在本文中，我们来看看这些应用程序的原理和用于构建它们的软件框架；今后在第二部分的文章中将更详细地研究一些应用程序，以及围绕这些工具的争议（特别是与隐私有关的）。
COVID-19 tracing principles
COVID-19追踪应用程序的主要目的是通知用户最近是否接触过受感染者，以便他们能够自我隔离或寻求检测。这些应用程序的创建通常由政府支持，由卫生当局和研究机构进行开发。COVID-19 apps这个维基百科页面列出了（截至2020年6月初）至少38个国家正在使用或正在开发的此类应用程序，以及至少8个框架计划。
这些应用可以追踪到与用户接触了相当长一段时间(例如15分钟)、物理距离很近(一米左右)的人。完整的追踪系统通常由手机应用软件和服务器软件组成。
对于距离测量以及检测附近其他用户，GPS和蓝牙是底层用到的技术。GPS只出现在少数项目中，因为它的精度不够，特别是在建筑物内。在地下停车场和地铁等封闭空间也无法使用。
大多数国家都选择使用蓝牙开发距离测量方案，一般是Bluetooth Low Energy（BLE）版本，比经典蓝牙的能量消耗更少。这一点很重要，因为距离测量是由手机完成的，所以蓝牙在大部分时间都需要处于激活状态。
不过蓝牙协议并不是为这类任务而设计的，所以人们一直在研究如何精确测量距离。泛欧隐私保护近距离追踪项目（Pan-European Privacy-Preserving Proximity Tracing project）的一份报告显示，使用BLE信号强度，特别是接收信号强度指示（RSSI）来测量距离是个可行方案。在使用蓝牙的接触追踪系统中，距离测量是由两部手机使用特定的信息格式进行通信。由于不同应用的数据格式不同，所以只有当两部手机都使用相同的应用程序方案时，才能保证通信正常进行。
Centralized versus decentralized
储存和交流密切接触者，是COVID-19追查应用程序的主要功能。这主要有两种方式：集中式和分散式，而应用程序可以混用两种模式。
为了了解这两类系统的区别，我们需要看一下用户识别的工作原理。每个用户都会获得一个随机的全局ID号，在集中式里，这个ID号来自于一个中心主管部门，分散式系统中则是由应用程序生成的。由于这是用户的全局标识，所以它揭示了用户的身份。为了保护隐私，在记录两个人的相遇事件时，这个全局ID绝不会告知相邻设备（即其他手机），不过可能是要传递给中心服务器的。相应地，全局ID被当作种子，使用加密哈希函数(如SHA-256)或HMAC来生成临时ID，并且是将全局ID和一个不断变化的值（如一个增加的数字或一个时间段的标识）配合在一起作为输入的。临时ID经常变化，例如每15分钟变化一次，它们会被广播给其他用户记录下来作为相遇事件。
集中式系统使用一个独立服务器（通常由卫生部门控制），生成并存储用户的全局ID。当用户被感染后，他们的联系记录会被上传到卫生部门。接触过的人就会得到通知。技术解决方案各不相同，有的是手动操作，有的是在应用程序中自动操作。这个过程由卫生部门处理，用户应用只是收到一个结果。
分散式系统依靠用户的手机来生成全局和临时ID。在这些系统中，全局ID也可能会定期变化。当用户被感染时，他们应该将自己的临时ID，或者生成临时ID所需的信息上传到一个通用服务器上。其他用户下载共享的感染数据，他们的应用程序会做匹配检查。本文（https://tcncoalition.files.wordpress.com/2020/05/tcn_component_based_comparison_between_privacy_first_exposure_notification_protocols.pdf ）详细介绍了几种不同的去中心化协议。
两种方法的主要区别在于由谁生成ID，中央服务器是否知道这些ID和与之相关的身份，以及由谁计算感染风险。两种解决方案都需要一个中央服务器来交换感染者的ID列表。
Frameworks
开发追踪系统首先需要一个密切接触者追踪协议，然后需要一个应用程序。应用程序通常由政府机构开发，它们使用现有的框架(协议)之一或创建一个新的框架。现在已经出现了许多这样的框架，其中大多数框架至少有一部分代码作为开源发布。本文中，我们来看看其中一些正在或已经在部署的应用程序中使用的框架。
Temporary Contact Numbers Protocol
第一个发布出来的框架是临时联系号码协议（TCN，Temporary Contact Numbers Protocol），最初由Covid Watch网站开发，然后由TCN联盟（TCN Coalition）维护。这个去中心化框架的源代码，包括协议和参考实现，基于Apache软件许可提供。
使用TCN的设备会广播随机生成的、临时的身份ID，同时，设备会记录所有接收到的身份ID。Covid Watch白皮书对该协议进行了概述。实际的实现中，使用了从周期性变化的密钥中衍生出来的数字（TCN项目README提供了密码学细节），以尽量减少当一个人被感染时需要发送的数据集。只有当用户被感染时，所有由用户设备生成的密钥才会被发送到中央服务器。
TCN框架允许在实现的时候改变它的行为。例如，可以配置中心卫生部门是否需要验证确认感染报告。TCN已经（或曾经）用于一些追踪应用，包括美国的CoEpi和德国的ito。
Decentralized Privacy-Preserving Proximity Tracing
分散式隐私保护近距离跟踪（简称DP-3T或DP3T）是一种类似于TCN的去中心化协议。它是由一些欧洲研究机构开发的。其白皮书详细描述了该算法，并概述了它的安全特性。
种子值和临时ID的生成都是由手机来完成的，它还计算了感染的风险。手机只从卫生部门下载确定感染风险所需的参数（如接触时间、信号强度）。DP-3T还包括了一套额外功能来增加隐私。所有运行该应用的手机都会上传假的接触数据，以最大限度地降低感染用户被暴露出来的风险。它还有一个选项，允许感染用户拆分和编辑报告，例如排除某些日子或时间段。
DP-3T的源代码在Mozilla Public License 2.0下提供，该项目内部还正在开发Exposure Notification API的一套具体实现代码。
Exposure Notification API
Exposure Notification framework框架是谷歌和苹果在2020年4月发布的。它似乎受到TCN和DP-3T的启发，并与它们有许多相似之处。它同样使用了周期性变化的密钥（它的密码学规范文档中给出了细节）。
在TCN、DP-3T或其他框架中原本属于应用层的协议，在Android和iOS中实现后形成Exposure Notification API提供了出来。它包括近距离检测，遇到的密钥会被记录，但不会对感染事件进行通知（这部分需要在应用本身实现）。Exposure Notification API只能用在公共卫生当局提供的应用程序中。规范是任何人都可以看到的，但是实现出来的源代码没有公布出来。谷歌的条款包括对应用程序的一些具体要求，包括：每个国家只能有一个应用程序，公共卫生机构必须对所有存储的数据负责，并且应用程序中不允许有广告。
有一个安卓系统上的参考应用，还有一个服务器实现的例子，都是Apache许可证发布的源代码。自该框架发布以来，被移植到该框架的应用包括意大利的Immuni（AGPL 3.0下的源代码）和波兰的ProteGo Safe（GPL 3.0下的源代码）。另一个例子是Covid Watch，它是TCN最初的支持者之一，但它的应用程序在2020年5月用Exposure Notification framework取代了TCN。
Exposure Notification API解决了许多独立应用遇到的一个问题（BlueTrace论文在第7页描述了这个问题, https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf ）：在iOS上，只有当应用处于前台时，蓝牙位置测量才有效。由于法国应用没有使用该API，法国政府已经要求苹果允许其他应用使用后台蓝牙。
Application and beyond
在这篇文章中，我们介绍了密切接触者的追踪应用的目的、使用的技术、并描述了它们以这种方式工作的原因。在即将到来的第二篇文章中，我们将更深入地研究一些特定的应用程序（使用现有框架或开发自己的协议）。我们将看看它们是如何工作的，同时也会涵盖它们的开源情况。最后，我们将考虑关于部署这些应用的争议和遗留问题。
全文完
LWN文章遵循CC BY-SA 4.0许可协议。
欢迎分享、转载及基于现有协议再创作～
长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～
