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深度文章以及开源社区的各种新近言论~

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值