技术分析：苹果 Google 的「健康码」怎么追踪疫情又保护隐私？

苹果的创始人乔布斯曾经因为感到背叛，和 Google 的前董事长施密特势不两立。

而如今全人类面临新冠病毒威胁，两家一度不共戴天的公司走到了一起，共同开发了一套接触者追踪 (Contact Tracing) 技术。

因为它一定程度上可以起到流行病学追溯和感染风险警报的功能，这个技术也被昵称为美国版「健康码」。

今天硅星人带你了解一下 Contact Tracing 的工作原理。

「三码合一」，匿名追踪

Contact Tracing 的工作原理大致如下：

设备之间通过低功耗蓝牙 beacon 的方式，同时作为发送者和接受者，交换并保存彼此的信息。

当某人甲确诊之后，甲的设备信息上传到云端的一个确诊者资料库，所有的用户都会每天从这个云端资料库下载信息并在本地查验。如果乙曾经收到过相同的信息，则可以认为乙是甲的接触者。

当然，如果直接使用设备唯一识别信息，会有较大的隐私风险。所以出于隐私保护的目的，苹果和 Google 费尽心机设计了一个 「三码合一」的机制。

为了方便更多读者理解，我们简单把这三码分别简称为 A、B、C 码。

• 首先，每台用户的手机都会生成一个固定不变的 A 码，不会上传；
• 通过 A 码，手机可以每天生成一个 B 码，平时不会上传；
• 既然要实现接触追踪，所以手机需要每隔一段时间（API 建议的是 15 分钟）对外广播一次。此时广播出来的是用 B 生成的 C 码，每 15 分钟/一个广播周期内更新一次。平时只有这个 C 码会被上传。

由于这种 Contact Tracing 是通过 API 实现的，iOS 和 Android 设备都可以互相广播和接收。

通过这种设计，苹果和 Google 希望最大限度确保：

1）交换的信息本身是匿名化的；

2）即便满足隐私保护的要求，在需要的时候仍可以对信息进行解密，定位到接触者。

稍微详细点的解释：

A 码叫做 Tracing Key，在手机上首次启动 Contact Tracing 时生成，长度为 32 字节，设备唯一，不会变化。虽然名字里有个「追踪」，实际上 A 码不会被上传，只保存在手机上，也没有识别作用，只是作为下一步计算 B、C 码时的输入。

A 码是一个随机数，使用加密学随机数生成器 (CRNG) 生成。

当你首次在自己的 iPhone 或者 Android 手机上使用其它政府、公司或机构基于苹果 Google 方案开发的接触追踪软件时，你的手机就会自动生成这样随机、唯一的 A 码。

这个码和你手机的已知识别码，比如序列号、mac 地址，都没有关系，而且不会上传，所以几乎不存在隐私风险。

B 码叫做 Daily Tracing Key，是从 A 码使用 HKDF 函数派生而来的，长度为 16 个字节。每 24 小时更新一次，

B 码没事的时候也不会上传。它平时的主要作用是作为输入，生成 C 码。只在确诊时，B 码才会派上用场。如果用户健康且没有接触风险，B 码也是永远保存在手机上的，不会上传。

假设用户甲在过去几天内和确诊的乙发生过接触，存在感染的风险，甲在这几天里的 B 码就会被作为「诊断码「(Diagnostic Keys)，被提取用于确认身份。B 码只在此时才会被提取走。总的来说，不管怎样，B 码都不会被默认（自动）上传。

上传的 C 码又是什么呢？

C 码叫做 Rolling Proximity Identifier，是对 B 码进一步进行加密生成的消息认证码 (HMAC)，长度为 16 个字节，通过低功耗蓝牙每 15 分钟对周围的所有设备广播一次，安装了 Contact Tracing 的手机可以接收到并保存这个码。

为了保护隐私避免追踪，从蓝牙 4.2 版本开始设备的蓝牙 MAC 地址可以随机变化。顺应了这一点，Contact Tracing 会在每次蓝牙 MAC 地址改变的时候，生成一个新的 C 码。

除了广播出去之外，手机还会保存在过去一段时间内生成的所有 C 码，用于在追踪接触者时进行校验。

如何追踪接触者？

如果你理解了前一节，那么这里就更好理解了。

我们假设甲确诊了，比如追溯期是 14 天内，就用甲手机在过去 14 天里的 B 码作为「诊断码」，上传到云端。

所有用户的手机每天都会从服务器下载一次所有的确诊患者的诊断码，然后在本地采用和计算 C 码一样的加密算法算一遍。

我们假设过去 14 天里甲和乙曾经共处一室一段时间，那么乙的手机上肯定保存了来自甲的 C 码。如果乙的手机经过计算，得到的 C 码出现在自己保存的过去 14 天的记录里，就完成了接触者的追踪和验证。

苹果和 Google 发布的 Contact Tracing 蓝牙工作原理提供了一张图片，阐释这个过程：

优势和劣势

总的来说，这套技术实现方式最直接的优势，就是在满足功能的前提下最大限度保护用户隐私。

在 Contact Tracing 加密和蓝牙工作原理白皮书中，两家公司指出，前两种码的生成周期是固定的，能够避免其它应用获取并用于无关的追踪目的。

上传的信息中不包括地理位置信息，严格仅限使用低功耗蓝牙 beacon。

C 码是和 B 码绑定的，没有 B 码，获得了 C 码也没有意义。

比方说某国政府用这套 API 开发了一个追踪工具，管理员在服务器端也是无法了解到某健康用户接触了哪些其它用户——管理员只可以对确诊患者这样做。

即使有确诊患者出现，对其上传的诊断码的计算也只是在其它用户的手机上进行，而非在服务器端。

由于设定了蓝牙广播和扫描间隔，以及每个 C 码的长度只有 16 字节，这套技术实现方式也比较省电、省存储空间。总体来看，它的电量消耗应该不会很可观，至少不会达到夸张的成都。当然，具体的广播和扫描间隔可以由追踪工具的运营者自行设定，苹果和 Google 也建议运营者考虑电量消耗。

苹果和 Google 还在白皮书中告诫追踪工具的运营者，不要从用户的手机上提取其它无关的元数据。

这套技术实现方式也有一些劣势。

其中最直接的劣势，来自于蓝牙本身的工作原理。

低功耗蓝牙的最远理论距离可以达到 100 米，而且也有一定的穿墙能力（隔一堵水泥墙往往没什么问题，金属的阻隔效果更强）。

这意味着如果你只是在空气流动的户外隔着几十米「擦肩」了陌生人，或者明明和他分别处在两个房间，只要你们的手机都装了 Contact Tracing，都开了蓝牙——只要那人被确诊，你也有很大可能「不幸」成为接触者。

另外，有人应该能看出来 Contact Tracing 是不完善的：就算发现并通知了接触者，仅靠这个机制本身，无法定位到他。知道自己成为接触者的，只有接触者本人。接下来他是否愿意主动配合居家隔离，最终还是依赖于个人意志，权威机构很大程度上是无能为力的。

这些功能可能需要 app 开发者自行开发，但是这样做的话也一定程度违背了 Contact Tracing 隐私保护设计的初衷。

针对这一点，苹果和 Google 提供的说明书写到，当接触者收到通知之后接下来该怎么做，需要卫生部门的网站或 app 进一步说明。

另外也存在一种捣乱的可能性，就是故意生成并广播大量的伪造的 C 码。不过除了占据用户手机的储存空间之外，目前这种攻击方式还没有其它可见的危害。

当然，这还只是一个相对比较早期的技术，苹果和 Google 也不是实际的实施者，具体使用的效果要看采用这套技术的政府或其它公司。

iOS 和 Android 的 API 已经发布在两家公司的网站上。值得注意的是，苹果的 API 是用 Objective-C 写的……

你对苹果和 Google 的 Contact Tracing 技术怎么看？

（本文来自微信公众号「硅星人」，作者杜晨，编辑 Vicky Xiao，爱范儿经授权发布。）