Lib.rs

› 硬件支持
#contact #protocols #report #tracing #devices #numbers #bluetooth

tcn

TCN协议的去中心化接触追踪的参考实现

由 Henry de Valence 提供

2 个版本

0.4.1 2020年4月8日
0.4.0 2020年4月8日

#893 在 硬件支持

MIT 许可证

45KB
311 行

TCN 协议

这是一份正在进行的文档。更改通过PR和问题进行跟踪。

本文件描述了由 TCN联盟 开发的 临时接触号码，这是一种以隐私为首要考虑的去中心化接触追踪协议。该协议旨在可扩展，以提供接触追踪应用程序之间的互操作性。TCN协议和相关工作是以 接触追踪权利法案 为指导思想设计的。

协议不需要任何可识别个人信息的，尽管它与受信任的健康部门兼容，但不需要。用户的设备通过蓝牙发送短距离广播到附近的设备。后来，如果用户出现症状或检测结果呈阳性，他们可以以最小的隐私损失向其联系人报告其状态。未发送报告的用户不会泄露任何信息。使用TCN协议的不同应用程序可以互操作，并且该协议可以使用验证的测试结果或通过可扩展的报告备忘录字段进行自我报告的症状。

欢迎直接向此存储库提交PR和问题。有关TCN协议的问题或更详细的合作，请联系 Henry 或 Dana。

此存储库还包含一个用Rust编写的TCN协议参考实现。通过运行 cargo doc --no-deps --open 来查看文档，并通过运行 cargo test 来运行测试。

为了协调开发，协议使用 Semver 进行版本控制。更改可以在 CHANGELOG.md 中找到。

本页内容

由于这是一个正在进行的项目，因此此页还包含 粗略笔记，尚未合并到主文档中。

接触追踪系统中的理想功能和信任假设

密码学构建了中介和重新排列信任的系统，因此在开始讨论接触追踪的密码学方法之前，值得明确界定问题中涉及的信任类别。

  1. 位置隐私。是否有任何一方被信任访问位置数据，如果是的话，在什么情况下？由于接触者追踪系统允许用户向其他用户报告可能的暴露，这个类别可以有效地细分为报告者隐私和接收者隐私。

  2. 功能能力。系统是否信任卫生当局能够执行其职能，或者如果他们变得不堪重负而无法做到，系统是否具有弹性？

  3. 报告完整性。如果有的话，系统使用什么措施来确定症状报告或检测状态的完整性？

接触者追踪用于识别可能接触过感染的人，并通知他们他们的暴露情况，以便进行隔离、检测或治疗。然而，接触者追踪也带来了自身的风险，例如基于健康状况的污名化或歧视的恐惧，或者接触者追踪系统可能被政府或个人用于监控的风险。这使得位置隐私至关重要。

然而，对功能能力的信任也存在问题。在一个理想的世界里，卫生当局将拥有无限资源，并完美有效地部署它们。但在现实世界中，卫生当局资源有限，在应对疫情的重压下感到压力，或者可能无法充分或有效地做出反应。事实上，这些可能性在当前的疫情中都已经发生了。虽然没有任何技术系统可以适当弥补制度上的失败，但具有弹性的系统可以吸收松弛并给予人们自我帮助的能动性。

此外，比没有增加对卫生当局负担的协议（例如，要求他们部署复杂的密码学如MPC或谨慎管理密码学密钥材料）的协议，具有严重的采用障碍，因此减少信任要求可以加速部署。

因此，似乎更倾向于设计一个不需要任何卫生当局参与的协议，但可以选择性地与验证报告完整性的卫生当局兼容（例如，通过将报告发送到代表卫生当局签名的门户网站，或者允许当局生成将经认证的阳性诊断结果传递给应用程序的URL）。将报告完整性的问题作为应用级问题意味着不同的应用程序可以做出不同的选择，同时仍然保持互操作性。例如，CoEpi允许用户自行报告症状，而CovidWatch则信任卫生当局证明阳性检测状态的完整性。

此分析使我们能够描述接触者追踪协议的结构和理想功能。协议的交互应适合以下阶段

  • 广播：用户通过蓝牙向附近的设备生成和广播临时接触号码（TCNs）。
  • 报告：用户上传数据包到服务器，向他们在某个时间段内可能遇到的用户发送报告。
  • 扫描：用户监控服务器发布的数据，以了解他们是否收到任何报告。

理想情况下，协议应具有以下属性

  • 服务器隐私：一个诚实但好奇的服务器不应了解任何用户的地理位置或联系人信息。
  • 来源完整性：用户不能向他们没有接触过的用户或代表其他用户发送报告。
  • 广播完整性：用户不能广播他们没有生成的TCNs。
  • 无被动跟踪：监视蓝牙连接的被动对手不应能够了解未发送报告的用户的位置信息。
  • 接收者隐私：收到报告的用户不向任何人透露信息。
  • 报告者隐私：发送报告的用户不会向未接触过的用户透露信息，只向接触过的用户透露接触时间。请注意，在实践中，仅时间本身可能仍然足以让他们的接触者了解他们的身份（例如，如果他们的接触者当时只有另外一个人）。

在这些属性中，广播完整性非常难以实现，因为它需要在物理层进行身份验证，以防止用户重新广播他们从其他用户观察到的TCNs。然而，它阻止的攻击是敌对者创建合法用户的幽灵副本，这种攻击需要敌对者携带设备，因此扩展性不好。在接下来的内容中，我们不尝试实现广播完整性。

一个初步协议

作为制定满足这些属性协议的第一步尝试，我们考虑一个草稿协议。所有运行该应用的移动设备定期生成一个随机TCN，存储TCN，并使用蓝牙广播。同时，该应用还监听并记录其他设备生成的TCN。为了发送报告，用户（或代表他们行动的健康当局）将他们生成的TCN上传到服务器，以及包含特定应用报告数据的备忘录字段。所有用户的程序定期下载报告TCN列表，然后将其与他们观察和记录的TCN列表进行比较。这两个列表的交集是积极的接触者集。

直观地说，这提供了服务器隐私，因为服务器只观察一个随机数列表，并且不能在没有与其他用户串谋的情况下将它们与用户或位置相关联。它阻止了被动跟踪，因为所有标识符都是随机生成的，因此彼此之间不可链接。它提供了接收者隐私，因为所有用户都下载相同的报告TCN列表并本地处理。如果适当地分批处理TCN列表，发送报告的用户不会向观察TCN的用户泄露超出接触时间的信息。

然而，这个提议并没有提供源完整性。因为TCN没有结构，没有什么可以阻止用户观察另一个用户广播的TCN，然后将其包含在发送给服务器的报告中。请注意，即使在健康当局验证报告的设置中，这仍然是一个问题，因为他们可以证明测试结果，但他们无法验证TCNs。这也提出了可扩展性问题，因为报告包含用户在整个报告期间广播的每个TCN列表，并且所有用户都必须下载所有报告。

TCN 协议

为了解决可扩展性问题，我们从纯随机TCN更改为从某些种子数据确定性生成的TCN。这减少了报告的大小，因为它只能包含紧凑的种子数据而不是整个TCN列表。这种改变以可扩展性换取报告者隐私，因为从同一报告派生的TCN是可链接的。然而，这种链接只能由观察了同一报告的多个TCN的各方实现，而不是所有用户。不同的报告不可链接，因此用户可以提交多个部分报告，而不是提交整个历史记录的单个报告。报告轮换频率调整报告者隐私和可扩展性之间的权衡。

为了解决源完整性问题，我们还将派生的TCNs绑定到用户持有的秘密上，并要求他们在提交报告时证明对该秘密的了解。这个证明（以数字签名的形式）可以传达给其他用户以供公开验证，或者仅由服务器检查。

密钥派生。

报告密钥生成。用户代理创建报告授权密钥 rak 和 报告验证密钥 rvk，作为签名方案的签名和验证密钥。然后它计算初始的 临时联系人密钥（TCK） tck_1 如下：

tck_0 ← H_tck(rak)
tck_1 ← H_cek(rvk || tck_0)

每个报告最多可以包含 2**16 TCNs。 H_tck 是一个输出为256位的域分隔散列函数。

TCK 摆轮。联系人事件密钥支持 摆轮 操作

tck_i ← H_tck(rvk || tck_{i-1}),

其中 || 表示连接。如以下所述，TCK 摆轮与蓝牙层的MAC轮换同步至关重要，以防止可链接性攻击。

TCN 生成。一个临时联系人号码是通过从临时联系人密钥计算得到的

tcn_i ← H_tcn(le_u16(i) || tck_i),

其中 H_tcn 是一个输出为128位的域分隔散列函数。

图示。密钥派生过程在以下图中说明

      ┌───┐
  ┌──▶│rvk│─────────┬──────────┬──────────┬──────────┬──────────┐
  │   └───┘         │          │          │          │          │
┌───┐       ┌─────┐ │  ┌─────┐ │  ┌─────┐ │          │  ┌─────┐ │
│rak│──────▶│tck_0│─┴─▶│tck_1│─┴─▶│tck_2│─┴─▶  ...  ─┴─▶│tck_n│─┴─▶...
└───┘       └─────┘    └─────┘    └─────┘               └─────┘
                          │          │                     │
                          ▼          ▼                     ▼
                       ┌─────┐    ┌─────┐               ┌─────┐
                       │tcn_1│    │tcn_2│      ...      │tcn_n│
                       └─────┘    └─────┘               └─────┘

请注意，了解 rvk 和 tck_i 足以恢复所有后续的 tck_j，因此所有后续的 tcn_j。

报告。

希望通知他们在 j1 > 0 到 j2 期间遇到的联系人用户准备了一份报告，如下所示：

report ← rvk || tck_{j1-1} || le_u16(j1) || le_u16(j2) || memo

其中 memo 是一个长度为2-257字节的变长字节数组，其结构如下。然后他们使用 rak 生成 sig，即对 report 的签名，并将 report || sig 发送到服务器。

报告检查。任何人都可以通过使用包含的 rvk 检查 sig 在 report 上的有效性来验证报告的来源完整性，重新计算 TCNs 如下：

tck_j1 ← H_tck(rvk || tck_{j1-1})              # Ratchet
tcn_j1 ← H_tcn(le_u16(j1) || tck_{j1})         # Generate
tck_{j1+1} ← H_tck(rvk || tck_{j1})            # Ratchet
tcn_{j1+1} ← H_tcn(le_u16(j1+1) || tck_{j1+1}) # Generate
...

并将重新计算的 TCNs 与他们的观察结果进行比较。请注意，从提供的 tck_{j1-1} 导出的 TCN 不 包含在报告中，因为收件人无法验证它与 rvk 相关。如果客户端验证不重要，服务器可以选择从每个报告中删除尾部的64字节 sig。

备忘录结构。备忘录字段提供了一个紧凑的空间用于自由格式消息。这确保了该协议是应用程序无关的且可扩展的。例如，在 CoEpi 的情况下，备忘录字段可以包含描述自我报告症状的位标志，或者在 CovidWatch 的情况下，可以包含验证测试结果的签名。

备忘录字段长度为2到257字节，具有以下标签-长度-值结构

type: u8 || len: u8 || data: [u8; len]

data 字段包含0-255字节的数据，其类型由 type 字段编码，该字段具有以下含义

  • 0x0：CoEpi症状报告v1；
  • 0x1：CovidWatch测试结果v1；
  • 0x2-0xfe：预留供应用程序使用；
  • 0xff：预留（以后可以用于添加超过256种类型）。

参数选择。我们实现

  • H_tck 使用 SHA256，域分隔符为 b"H_TCK"；
  • H_tcn 使用 SHA256 和域名分隔符 b"H_TCN" 进行计算；
  • rak 和 rvk 作为 Ed25519 的签名和验证密钥。

这些参数选择导致签名报告的大小为 134-389 字节，或未签名报告的大小为 70-325 字节，具体取决于备忘录字段的长度。

测试向量可以通过以下方式生成：

cargo test generate_test_vectors -- --nocapture

通过蓝牙低能耗进行TCN共享

遵循此协议的应用程序使用 iOS 和 Android 应用程序的能力，通过蓝牙低功耗（BLE）与附近的设备共享 128 位临时联系人号码（TCN）。

使用 BLE 分享 TCN 应该在 iOS 和 Android 应用程序之间跨平台工作。

  • 跨应用程序。
  • 不要求用户访问其位置。
  • 高效节能，使用最少的 BLE 流量。
  • 当它们都在后台且设备屏幕锁定时。
  • 在应用程序之间，同时设备屏幕锁定。

满足上述要求时，我们遇到了以下 BLE 平台限制：

  • iOS 13.4（及更早版本）不支持在挂起或后台运行状态下的第三方 iOS 应用之间的可发现性，以及当设备屏幕锁定时。注意：如果用户解锁屏幕或启动一个应用程序（例如，Settings.app），它执行主动蓝牙扫描，那么可以。
  • iOS 13.4（及更早版本）不支持第三方应用程序的小广告数据广播，而 Android 支持多达 31 字节。

为了克服上述限制，该协议使用广播导向和连接导向的 BLE 模式来共享 TCN。这些模式中使用的 BLE 设备术语是：

  • 广播模式中的广播器和观察者。
  • 连接模式中的外围设备和中心设备。

在这两种模式中，协议使用 0xC019 16 位 UUID 作为服务标识符。

在广播模式下，广播器使用广告数据的服务数据字段（0x16 GAP）广播一个 16 字节 TCN。观察者从该字段读取 TCN。

在连接模式下，外围设备将其 UUID 为 0xC019 的主要服务添加到 GATT 数据库中，并对其进行广播。该服务公开一个可读和可写的特征，其 UUID 为 D61F4F27-3D6B-4B04-9E46-C9D2EA617F62，用于共享 TCN。共享 TCN 后，中心设备从外围设备断开连接。

临时联系人号码（TCN）的查找方式：

Android-Android、iOS-Android：1 观察到 2 的广播，并从广告数据中读取值。

Android-iOS：2 连接到 1，写入特征的值，然后断开连接。

iOS(F)-iOS(B)、iOS(B)-iOS(F)：1 连接到 2，读取特征的值，然后断开连接。

iOS(B)-iOS(B)：附近的 Android 设备充当桥梁：它通过特征写入请求接收到的 TCN，并将在范围内广播这些 TCN。

F = 前台应用程序

B = 后台应用程序

从 CoEpi + Covid Watch 生成的本地 TCN 并覆盖上述关键流量的通信的当前开源实现正在以下存储库中开发：

预期生成128位TCN的过程在不同平台上不会有所变化，但平台间通信TCN的过程已经在上述存储库中实现为工作版本。

参考文献和进一步阅读

贡献者

注释（将与主文档合并）

密钥轮换和压缩因子

一个重要的问题是，我们多久更换一次[报告]密钥。如果它不改变，那么在阳性测试中上传密钥就会暴露用户曾经接触过的所有人，甚至几个月前的人。在另一个极端，如果我们每次生成CEN时都更换密钥，那么我们就会回到原始的随机CEN，并再次面临可扩展性问题。什么是一个合适的折衷方案？

轮换考虑事项

密钥轮换间隔必须平衡安全性和可扩展性之间的权衡。例如，考虑每天轮换密钥。这应该会导致合理数量的数据被上传和下载。然而，这意味着任何测试呈阳性的用户都会通过泄露生成这些CEN的密钥，将当天他们广播的所有CEN联系起来。这有两个后果：1)其他用户可以“交换意见”，看看他们是否看到了由同一密钥生成的CEN，因此遇到了同一个人。2)用户在当天很容易被任何被动监听CEN并记录其位置的人追踪。

关于第一个问题的讨论得出结论，这是两个攻击中较不严重的一个。要积极发起攻击，需要用户主动寻找彼此，勾结并比较数据。最终的结果是推断他们与同一个人有接触。值得注意的是，在许多情况下，这可能对人类来说是可能的，只需通过比较他们交谈过的人，等等，或查看相遇的时间，并记住他们在哪里以及与谁见面。还可能的是，CoEpi应用程序将允许用户本地存储位置历史数据，以帮助确定接触发生的位置，以及这种接触可能代表潜在暴露的可能性。由于识别这种暴露是应用程序的全部目的，因此可以预期（通过用户报告症状或测试结果）接收并使用他们认为适当的信息。任何不适当使用此类信息的行为都需要通过社会手段而非技术手段来避免。

然而，第二个问题是一个主要关注点。BLE信标跟踪已经在某些环境中使用。此外，如果接触追踪应用程序变得普遍，企业和公共场所的联系人追踪解决方案将迅速出现。这将导致CEN被大量记录，并可能被云管理服务聚合。在这种情况下，将24小时的CEN连接起来将很容易，相当于简单地泄露用户当天的位置历史（如果他们后来报告了症状或阳性测试）。更糟的是，由于重新识别攻击的相对简单性，应该相当简单地将用户一周或更长时间的位置历史片段链接起来以计算历史记录。显著缩短间隔可以降低这种风险。这并不完全消除它，但作为对抗BLE信标跟踪的主要防御手段，重新密钥间隔应尽可能短。

请注意，但如果根据症状报告进行接触，则重新键入的问题就小得多。如果用户被告知了接触情况和他们的症状，并且症状描述相当独特，那么所有报告包含相同症状的CEN（接触事件通知）几乎可以肯定是来自同一用户。这与使用较长的重新键入间隔所泄露的信息相同。

进一步考虑

在CEN持续广播的环境中，我们还必须选择从一个CEN切换到另一个CEN的速率。同样，CEN持续时间越长，跟踪的风险就越大。特别是在许多情况下，当某个CEN消失而另一个CEN出现时，很容易推断出它们是同一台设备。这不会是完美的，但如果CEN很少改变，就不需要完美地恢复用户的位置历史记录。

最后，由于处理MAC地址和其他标识符，蓝牙本身暴露出许多跟踪机会。不幸的是，这些是否被适当随机化的程度在不同设备之间差异很大，许多设备没有实施强大的隐私保护。参见这篇论文以了解隐私问题的概述。在所有情况下，CEN持续的时间应该是BLE协议中MAC地址和其他标识符随机化频率的倍数。例如，如果MAC地址每分钟更改一次，那么CEN可以每分钟、每10秒或每秒更改一次。但不能每两分钟更改一次，例如每7秒更改一次。在后两种情况下，当MAC地址更改时，CEN不会更改。任何观察者（MAC A，CEN 1），然后（MAC B，CEN 1），然后（MAC B，CEN 2）可以得出结论，它们都是同一台设备，因为所有标识符不是同时更改的。这将完全破坏蓝牙隐私。

攻击

链接攻击

链接攻击是将匿名记录与不同数据集中的非匿名记录相匹配。对于我们的用例，一个例子是：在给定时间段内，一个用户只接近另一个人的。如果他们被告知了泄露的接触情况，他们就知道是谁。一般来说：如果接触的时间框架被泄露，并且用户进行了带外关联，例如记录笔记/拍照，他们可以缩小其接触者可能的真实身份，这被泄露了。只要用户知道哪些CEN在交集内，这就不能被阻止。

重放攻击

攻击者收集他人的CEN并重新广播它们，以在八卦阶段冒充另一个用户。如果不进行缓解，他们最多可以产生与非法泄露相同数量的假阳性（即他们不是感染源）。由于在上面的提案中，CEN的有效期将在泄露后知道，因此此攻击只能在短时间内执行。

CEN冲突计数

对于128位CEN，在全球人口为80亿的情况下，来自两周时间框架（泄露和非泄露）的所有合法生成的CEN的预期总冲突计数（未分片）约为1.7e-13（参见collisions.jl）。

依赖关系

~3MB
~66K SLoC