当地时间2020年4月10日，苹果与谷歌宣布将联手推出一项方案，利用蓝牙技术帮助政府和卫生机构减缓病毒蔓延，这项方案也被国内媒体解读为欧美版“健康码”。对于“健康码”这个概念，相信在国内的大家已经很熟悉了，疫情期间成为了防控工作的一个有效工具。当欧美版这个“健康码”新闻出来的时候，我们第一时间也关注到了这个新闻，第一反应是美国的互联网公司终于“抄作业”了。不过从我们对苹果和谷歌的技术细节进行深入了解之后，我们发现这个欧美版的“健康码”并不是直接抄作业，而是根据欧美国家的国情做了很不一样的设计，本文也将通过分析这项技术方案的设计原则来讲解欧美版的“健康码”到底哪里不一样。

笔者注：本文的技术分析基于苹果和谷歌官方技术文档，以及开源项目。DP-3T （Decentralized Privacy-Preserving Proximity Tracing）开源项目跟苹果和谷歌没有直接联系，DP-3T是由一群欧洲的科学家所发起的疫情追踪开放式协议，不过DP-3T所倡导的大部分设计思想已被苹果和谷歌采纳，因此本文的大部分内容都来源于DP-3T开源项目的白皮书。

国内版“健康码”

首先让我们来看看国内目前健康码大体的一个技术架构。根据我们对所见到的健康码分析研究，我们认为国内健康码大多采取的是中心化的大数据收集和分析模式，其具备以下几个特点：

中心化存储所有用户的行程和身份信息，方便统一进行大数据分析和调控。

没有确诊的用户数据也会上传，确保出现疫情的时候能够快速通知到密切接触人群。

收集的用户信息包含了身份信息，行程信息等敏感数据，方便进行数据关联分析。

数据生命周期不太明确，超过一定天数的数据是否删除掉没有统一标准。

基于以上几个特点，国内的健康码实行起来可以达到高效快速甄别密切接触人群的目的，不过一定程度上用户数据的隐私没有彻底的保护，数据被滥用的可能性也存在。那么，让我们看看国外是怎么设计的吧。

欧美版“健康码”

设计目标

由于欧美国家的对于数据隐私保护上有很强的监管，因此在设计疫情监控方案的时候，需要充分考虑到数据隐私保护的影响。同时，欧美民众天然对政府和大型企业缺乏信任，过度中心化的架构在做疫情监控上也会有不少主力，因此谷歌和苹果在提出他们的疫情监控方案时候，在同时满足能够快速确定密切接触人群的同时，需要满足一下几点数据隐私保护要求：

最小化收集的数据量。疾控部门应该尽可能的减少对数据收集的要求，同时确保数据匿名化，也就是脱敏。数据只保留能够快速追踪密切接触人群的最必要部分，任何机构都没法从这个数据里面获取敏感个人信息。

不上传没有确诊用户数据。用户在没有确诊的时候，在没有征得用户授权之前，数据不能上传到疾控部门那里，数据会一直留在用户自己的手机里面。

过期数据定期删除。所有数据应该有一个固定的过期时间，超过这个时间数据应该删除，进一步降低数据泄露的风险。

尽可能杜绝数据滥用。因为收集的数据量是极少的，而且在发送给后端之前已经进行了匿名化处理，数据被大规模滥用的可能性也会降到最低。

基于上述数据隐私保护要求，我们来看看欧美版的“健康码”，是如何具体设计的。

技术细节

简单来讲，欧美版的“健康码”采用蓝牙的BLE（Bluetooth Low Energy）广播技术，这项技术可以让设备通过低功耗蓝牙协议，向周围的近距离其他蓝牙设备进行广播信息。由于目前智能手机基本具备蓝牙功能，因此这个技术方案设计了一个在近距离接触其他设备时候的信息收集方式，让我们来看看是他们怎么做的。

首先，每个设备都需要生成Ephemeral IDs（临时身份标示符）。EphID生成是依赖某种密码学算法，因此需要一个私钥SK。这个私钥为了确保安全，是需要每天进行更换，当天的私钥是根据前一天的私钥的某种哈希值而生成：

另外为了进一步确保EphID的匿名性，该设计要求每天需要生成若干个新的EphIDs，根据相应的时间间隔进行轮换。这个轮换的时间间隔是可以按照分钟进行配置，假如是30分钟，那么每天需要生成48个EphIDs以供轮换。生成EphIDs的算法如下：

PRF是个伪随机函数（例如：HMAC-SHA256），“broadcast key”是个固定公开的字符串，PRG是一个流加密函数（例如：AES CTR模式）产生n个16 bytes的EphIDs。然后设备可以将这个生成的n个EphIDs随机打乱顺序，然后依次进行使用。这些生成的EphIDs都会存在设备本地，以供后续使用。

当设备有了这些EphID来表示自己的身份之后，会在设备开启过程中持续向周围安装了同样服务的设备广播自己的EphID，因此这些设备在运行过程中都会存储除了自己的 EphID之外的，收到的其他人的EphID，以及一些包含了收到时间的辅助信息。这些设备本地会有一个数据过期时间的配置，例如14天，超过这个时间窗口的数据会被自动清除。我们可以算出来，如果一个人每天接触100个人，每个人每天有100个EphIDs，14天窗口内，可能需要存储140k个EphID，EphID的存储代价是32bytes，因此总体数据量是 4.2 MB，这是一个非常小的数据量了。

那么，当一个患者确诊之后的流程又是怎样的呢，我们可以参考上图：

1.患者主动或者被动（根据所在国政策）上传具有传染性第一天的私钥信息到后端服务器。这个后端服务器可以是互联网公司的云，也可以是政府机构的机房。

2.后端服务器在收到信息之后会广播确诊患者的私钥信息，给所有使用该服务器的设备。这种广播可以是通过推送的方式进行，也可以是手机设备通过定期轮询抓取的方式进行。

3.手机收到相关患者私钥信息之后，会在本地进行一些计算，以确认感染风险，如果感染风险高于阈值，会触发手机报警。

4.对于高于风险阈值的密切接触者，可以选择将自己与患者的接触信息，包括次数，相对时间等脱敏后的匿名数据，上传给疾控部门或者流行病学家。这种上传可以是定期批量上传，以节省手机的资源消耗。当然很重要的一点是，用户也可以选择不上传。

5.确诊患者在确保已完成私钥上传之后，需要重新随机生成一个全新的私钥，这样的话确保之后的隐私不会被侵犯。

根据以上的确诊患者的数据上报流程，我们可以总结这套设计方案有以下几个特点：

后端服务器扮演的是一个通信媒介的作用，本身不做大规模的数据存储和分析。这样就算是后端服务器被黑或者被滥用，也可以将隐私泄露的风险降到最低。

对于是否要分享自己的信息给疾控中心相关人员，用户有自己的选择权。对于不想共享这部分数据的用户，可以在自己的手机上关闭。

疾控中心收到的所有用户分享的数据全部匿名化脱敏处理，而且数据量非常有限。因此无法从收到的数据里面探知具体的位置信息，真实身份信息等等。

两种“健康码”比较

从上面我们对于两种“健康码”技术架构的分析来看，欧美版的“健康码”在隐私保护上的确有下足功夫，具体可以表现为以下几个优势：

数据收集量很小，每个人每天的数据量<1MB。

无敏感数据收集，数据匿名化处理，用密码学方法保证隐私性。

超过一定时间的数据会被清除。

未确诊患者数据无需上传，用户在数据上传上有选择权。

去中心化架构为主，中心化服务器只作为通信媒介。

不过，从我们对实际运行情况了解来看，这套方案在现实推广中也会遇到不少问题，总结来说我们认为会有以下几个劣势：

设备如果未开启蓝牙、蓝牙功能缺失或者遇到手机没有电，这部分工作就完全无法进行。

蓝牙传输协议的安全性有待商榷，已知已有多种针对蓝牙传输协议的安全攻击。

在人口密集区域，这套广播协议对设备电量损耗和实际传输成功效率都会有不少影响。

如果很大一部分用户不积极主动上传数据给疾控部门，疫情防控工作效率会大打折扣。

如果被不怀好意的人利用这套协议恶意提交错误数据，比如提交错误的接触数据等，会造成一定程度的错误判断。

所以，具体运行过程中这套协议是否能够有效，非常取决于所在地的国情，我们将继续观察这套技术协议在落地过程中的情况。

总结

本篇文章，我们介绍最近推出的欧美版“健康码”的技术架构和一些细节。我们可以看到国外的模式非常注重隐私和去中心化，这点值得学习。不过这套技术方案是否真正可行和效率高，还需要实际运行检验，我们希望在国外技术公司和政府部门努力下，这套模式能有个好的最终落地结果。