新Apple和Google联系人追踪协议述评
2020年4月24日，苹果和谷歌发布了新版本的苹果和谷歌联系人追踪协议，他们共同编写了该协议。现在它将被称为“暴露通知技术”，因为这个名称更好地描述了协议的性质。
4月29日，苹果发布了该协议的第一个iOS13.5测试版。此测试版面向API测试和收集反馈的开发人员。对API的访问将仅限于公共卫生当局授权的应用程序。
此次更新是对批评(其中大部分是毫无根据的)以及该协议1.1和1.2版本中实现的几个技术更改的回应。我们将在本文中讨论这些更改。
正如苹果和谷歌经常指出的那样，联系人追踪只是这一协议的一部分，但却是非常重要的一项。
这一努力背后的主要想法是通过提前通知潜在的感染者来减缓冠状病毒的传播。
正如上图所示，当一个人感染多个人后，当第一个人的冠状病毒诊断得到确认时(因为潜伏期约为14天)，大部分最近感染的人很可能还没有感觉到任何病征。相反，他们会感染其他人。
如果我们能设法在诊断时告知这些无症状的携带者感染他们的人，我们就可以防止连锁反应。从而极大地减少了感染的传播。
此方法可以帮助至少部分取消隔离限制。实施这个简单的想法可能会挽救许多国家的经济，苹果和谷歌联合起来完成这项任务是有充分理由的。
现在我们来看看旧的协议是如何运作的，新的协议应该是如何运作的。稍后将更详细地讨论新旧协议之间的其他区别。
一款安装了iOS或Android操作系统的智能手机上安装了一款应用，可以通过苹果和谷歌的联系人追踪API启动联系人追踪。
此密钥用于将跟踪密钥与当天的数字连接起来，生成HKDF形式的每日跟踪密钥。
此密钥用于将跟踪密钥与当天的数字连接起来，生成HKDF形式的每日跟踪密钥。
每隔10分钟，该密钥用于生成一个临时滚动接近ID，作为每日跟踪密钥的HMAC，并加入一个时间间隔数。该临时密钥使用蓝牙低能量广播。其他智能手机读取此密钥后会将其存储在本地。
一旦有人被感染，他们的最后14个每日密钥将被发布，所有其他设备在下载这14个每日密钥后，将生成所有14天的滚动邻近ID，并将它们与本地存储的滚动邻近ID进行比较。
如果匹配，你就与感染者有过接触。
您可以在我们发表的关于该主题的前一篇文章中找到更详细的描述。
每天都会生成一个新的随机16字节每日曝光密钥。它用于生成临时标识符的加密密钥(滚动接近密钥，或RPIKey)，以及元数据加密密钥(相关的加密元数据密钥，或AEMKey)：RPIKey=HKDF(ExpKey，NULL，UTF8(“EN-RPIK”)，16)AEMKey=HKDF(ExpKey，NULL，UTF8(“EN-AEMK”)，16)其中-HKDF(Key，Salt，Info。-NULL代表未使用的盐。-UTF8(“en-RPIK”)是与UTF8中的en-RPIK字符串相对应的字节数组。
BLE规范假定每15-20分钟更改一次MAC地址，以避免设备跟踪。每次更改MAC地址时，都会生成一个新的临时滚动邻近ID(RPID)密钥。RFID=AES128(RPIKey，UTF8(“en-RPI”)||0x000000000000||Ti)其中，AES128(密钥，数据)用于128位密钥的AES加密功能。-Key为第一步生成的RPIKey或Rolling Proximity Key。-DATA是以下各项的串联(||-SYMBOL表示串联)：-UTF8(“en-RPI”)是与用UTF8编码的EN-RPI行相对应的6字节数组。-0x000000000000是六个零字节(总共得到一个128位的块)。-ti-4字节，10分钟临时间隔，按unix_timeamp div(60*10)计算，div表示整数除法。接下来，对4字节的关联加密元数据(AEM)进行编码。规范中没有公开该元数据究竟是如何编译的。很可能，这样做是为了保留扩展协议的选项。我们将在本文后面更详细地讨论元数据。AEM=AES128AES CTR(AEMKEY，RFID，METADATA)，其中-AES128AES CTR(KEY，IV，DATA)用于−-CTR加密功能，AEMKEY是128位密钥。数据输出大小与数据输入大小匹配，因此不需要添加任何内容来匹配块大小。滚动接近密钥用作输入向量IV。接下来，将临时标识符滚动接近ID与关联的加密元数据组合，BLE有效负载如下所示：
这一批是通过蓝牙低能耗广播的。读取数据并随后将其存储在本地的设备。
3.一旦有人被感染，他们最近的14个每日密钥被发布，所有其他设备在下载这14个每日密钥后，生成所有14天的Rolling Apacity ID，并将其与本地存储的Rolling Proximity ID进行比较。
自该协议的第一个版本发布以来，新闻头条不断向每个人通报苹果和谷歌(Apple；Google)开发的一项追踪联系人的新协议。在只看了标题之后，大多数读者对另一个跟踪系统的印象是，没有任何东西(无论是匿名、加密还是本地数据存储)能阻止他们。
以前用于每日跟踪密钥生成的主私有跟踪密钥已被删除。在新版本中，每个曝光密钥(早先的每日跟踪密钥)都是随机生成的，因此即使在理论上也不可能在它们之间建立联系。
这种方法被用于由科学界开发的DP-3T协议中。您可以在我们以前处理此协议的一篇文章中详细阅读此协议。
因此，苹果和谷歌对批评的反应是保护协议免受两种可能的攻击：
如果入侵者发现了智能手机的旧备份，他们可以提取每日跟踪密钥，这足以生成新的每日密钥并广播虚假的新联系人。
如果入侵者设法找到链接的密钥，甚至，如果他们有大量的时间和计算机能力，猜测跟踪密钥(在某人被感染并发布每日跟踪密钥之后)，他们可以借助之前安装的BLE信标推断受感染的移动，或者他们可以创建假的新联系人(如果他们已经设法计算出跟踪密钥)。
每10分钟生成一个临时密钥不是问题，但是，这可能会对从服务器下载的密钥起作用。例如，某一天，在一些大国，有10.000人报告了新的感染病例。这将创建14万个每日密钥，或者智能手机需要生成的140K*144~2000万个临时密钥(每天创建144个临时密钥，24*60/10)。通过比较并检查联系人日期号码的所有每日密钥，而不是生成所有可能的临时密钥，可以优化匹配。在这种情况下，如果您每天有大约10个联系人，即每两周140个联系人，您的手机将需要进行140*10K=140万次操作，这是一个相当可观的数字。许多现代智能手机支持AES加密的硬件加速，这使它们能够更快地匹配联系人，并使用更少的电池电量。
在规范的第一个版本中，每10分钟生成一个临时标识符滚动接近标识符。同时，蓝牙低能量MAC每隔15到20分钟更换一次，间隔不同。由于RPI和MAC更改不同步，因此可以将新MAC与旧RPI关联，或将新RPI与旧MAC关联。这一错误可能允许跟踪用户的移动，例如，在交易中心，使用BLE信标。新版本的协议同步了MAC和RPI更改。引述如下：“密钥时间表是固定的，由操作系统组件定义，从而防止应用程序包含可用于跟踪的静态或可预测信息。”
不在系统级别但在应用程序级别工作的协议不能以这种方式同步MAC和RPI更改。因此，DP-3T协议和OpenCovidTrace在访问BLE服务的时刻生成临时标识，并且这些标识不会被广播。
加密元数据的出现是规范中最神秘的变化。目前还不清楚它将包含什么内容，以及谁将有权访问它，所以让我们试着猜测一下。
它每隔15到20分钟在我们的设备上生成和加密一次，大小只有4个字节。它可以是以下内容之一：1)有关我们设备的信息；2)时间；3)位置(不精确，因为限制为4个字节)；4)时区；5)发布此特定应用程序的组织；6)可能是由发布此应用程序的组织分配给您的ID。
它会被广播到附近的所有设备(尽管它是加密的)，其他人都不会拥有这些信息。如果受到感染，此数据不会上载到服务器。因此，只有您联系过的设备才能获取此数据。假设这是您的联系人不拥有的某种数据，这将是合乎逻辑的，这使得时间和地点选项变得不太可能。不过，即使此协议中不使用此数据，一些开发人员可能会将其用作排序的扩展。关于您的其他数据很可能存在。
只有在其中一个用户受到感染并共享可用于生成密钥和初始化向量以解密此数据的日常密钥之后，才能解密此数据。因此，只有在感染的情况下，此数据才是重要的。
计算接触距离所必需的电话型号、代码或蓝牙发射器的功率。
应用程序的代码，或发布此应用程序的组织或国家/地区的代码，以便可以知道谁确认了诊断。
最坏的情况是，这可能是一些内部ID，允许使用此协议的应用程序的开发人员使其不是匿名的，尽管此协议一开始声明了所有内容。在他们的数据库中，开发者可以使用元数据中的ID将每个用户的数据与协议使用的匿名标识符联系起来。在感染的情况下，可以找出可能感染您的用户的ID并请求此信息。
苹果和谷歌已经表明，他们能够接受批评，并迅速做出反应。协议的改变消除了几个安全问题，提高了匹配受感染联系人的性能，并为应用程序开发人员增加了新的选择。
然而，主要的问题是，当涉及到用户的联系人和移动数据的隐私时，用户对IT巨头的不信任不太可能消失。这不是简单地通过更改协议名称就能解决的。
我们OpenCovidTrace确信，这种社会重要性的项目必须以开源方式实施，我们用户数据的安全和隐私需要得到专业社区的确认。
这就是为什么我们在开源平台OpenCovidTrace上工作，它支持DP-3T协议，并实现了Apple&；Google协议，但由于iOS的限制而做出了一些改变。
加入我们的Github吧！您的意见和反馈将有助于我们项目的发展，在隔离解除后，我们将能够共同扑灭冠状病毒的爆发。
由欧洲科学界开发的接触者追踪协议DP-3T的https://github.com/DP-3T/-Github储存库。https://opencovidtrace.org-我们的开源项目
