马上上线!谷歌与苹果联手抗疫,打造基于蓝牙设备的接触史回溯 | 凌云时刻...
发布日期:2021-06-30 18:30:52 浏览次数:2 分类:技术文章

本文共 4983 字,大约阅读时间需要 16 分钟。

凌云时刻 · 故事

导读:四月中旬,谷歌与苹果一同发布了利用低功耗蓝牙技术追踪新冠接触者的合作计划 [1] ,将在不牺牲个人隐私的前提下,帮助安卓和iOS系统用户确定他们是否曾经接触过新型冠状病毒肺炎患者。本文主要介绍该技术的实现原理以及讨论该技术在隐私性方面提供的保护机制。

作者 | 阿里巴巴冷劲

来源 | 凌云时刻(微信号:linuxpk)

一、具隐私性保护的低功耗蓝牙接触追踪技术

近距离接触为 COVID-19 已知的最主要传染途径,因此各国政府也将追踪确诊患者过往的接触历史作为防止疫情扩大的重要工具。

目前谷歌与苹果正计划推出一项名为 Contact Detection Service (接触检测服务)的解决方案,该方案包括应用程序编程接口(API)以及操作系统层面支持。

第一阶段,两间公司会在5月份一同发布能让安卓和 iOS 系统在低功耗蓝牙协议层面互通的API,保证各国的卫生当局的APP速度接入。

在未来的几个月内,谷歌与苹果更会进一步将该功能内建至操作系统中,用户可以自行决定是否加入该计划以及是否要接入相关卫生当局的管理体系中,此外谷歌与苹果对用户提出以下几点保证[2]:

  • 在 Contact Detection Service 功能被激活之前,会先取得来自用户的明确同意 

  • 该功能不会收集个人识别信息或是所在位置信息 

  • 用户的接触信息将只保存在手机内,不会泄露给他人 

  • 用户个人的确诊信息将无法被他人识别,包括谷歌与苹果 

  • 该信息只会被用于 COVID-19 疫情管理

二、具体的落地范例

在此以 Alice 跟 Bob 的故事作为该技术的落地范例。

某一天下午, Alice 跟 Bob 做了近十分钟左右的短暂会谈,在他们聊天的过程中,彼此的手机蓝牙也在背地里交换了经隐私匿名处理的的蓝牙 beacon 信息并存储在手机中。

图1:Alice跟Bob的短暂会谈 [4]

几天之后 Bob 确诊,他将确诊结果输入到卫生当局的 APP,并且同意将他过去14天用于产生匿名蓝牙 Beacon 的秘钥上传至云端,供其他用户下载进行比对。

图2:Bob确诊 [4]

另一方面,同样使用了该技术的 Alice 会定期连上卫生当局的服务器去下载 COVID-19 确诊患者的 Beacon 秘钥。

由于 Alice 跟 Bob 曾经接触过,因此当 Alice 下载了由 Bob 自行上传至云端的蓝牙 Beacon 的秘钥后,可以经比对到由 Bob 的蓝牙设备所发出的匿名蓝牙 Beacon ,得知自己曾经跟已确诊者接触过。

图3:Alice定期下载确诊者的蓝牙Beacon秘钥进行比对 [4]

此时 Alice 的 APP 会发出告警通知,并且由 APP 的发行当局告知 Alice 接下来怎么跟进处理。

图4:APP发出告警通知 [4]

估计一般人对于 Contact Detection Service 最感兴趣的点,是怎么做到匿名性及隐私性,它的原理跟蓝牙规范里可解析私人地址 (Resolvable Private Address, RPA) 相似,在此解释如后。

三、Contact Detection Service技术细节

由于蓝牙设备一般都跟用户个人的身份/实体位置关系比较紧密(例如手机、耳机、智能手表等蓝牙产品),蓝牙联盟为了提高透过蓝牙设备来追踪用户的复杂度,因此发明了可解析私人地址 (Resolvable Private Address, RPA)。

当使用上RPA时,只有两个彼此先前已经做过蓝牙配对并交换过身份解析秘钥 (Identity Resolving Key, IRK) 的设备才有办法解析RPA来识别对方身份。 

RAP 的格式为48 bits,其中 24 bits 为一随机数 prand,剩下的24 bits则是透过将 IRK 与 prand 作为蓝牙规格里定义的 ah 函数输入所产生的 hash 值。

具有 IRK 的接收方在收到 RPA 后,可以利用同样的方法取出其中的 prand 部分,再搭配IRK推导出 local hash ,如果 local hash 与 hash 的结果一致,则可推断对方是一个曾经跟自己配对过的设备。

图5:RPA的生成与解析

使用 RPA 的设备会用 RPA 来做蓝牙设备的广播地址,广播接收方若有对应的 IRK 可以在解析 RPA 之后得知该设备的真实身份。

 Contact Detection Service 原理

谷歌与苹果共同制定的 Contact Detection Service 原理与 RPA 相似,当中会使用到三把秘钥与一个标识符,本文只阐述其生成原理如下,更多技术细节可以参考文档 [6] 。

追踪密钥 (Tracing Key):追踪密钥为32个字节,由设备自行依据规范 [5] 产生,该密钥永远不需要与他人分享,其产生公式为:

 

追踪密钥会被安全的存放于设备中。

每日追踪密钥 (Daily Tracing Key):每日追踪密钥为16个字节,依据规范 [5] 以追踪密钥作为输入后产生,每24小时会刷新一次,其产生公式为:

  左右滑动查看完整公式 

 

当中   为该密钥某日被使用时的 DayNumber,每24小时会变更一次。

诊断秘钥 (Diagnosis Key):诊断秘钥是每日追踪密钥的子集合,当用户确诊时,会将其过往某段时间内用的每日追踪密钥作为诊断秘钥分享给其他人。

滚动接近标识符 (Rolling Proximity Identifier, RPI):RPI为16个字节,一样是依据规范 [5] 以每日追踪密钥作为输入所产生,为避免用户被锁定追踪,规范建议每15分钟会刷新一次,其产生公式为

  左右滑动查看完整公式 

当中   是每次 BLE MAC 地址发生变动时对应的 TimeIntervalNumber;为了防止被追踪,RPI 跟蓝牙设备广播时用的 BLE MAC 地址必须同时更换。

Contact Detection Service 的蓝牙 Service UUID 为 0xFD6F,在功能被激活后,蓝牙设备会持续广播带有该 Service UUID 的报文,同时也扫描带有该 Service UUID 的报文,并将其中所带的 RPI 给保存起来,为日后追踪比对使用。

当有用户出现确诊的情形时,可以自愿地将诊断秘钥上传至诊断服务器,给其他用户下载、比对之前经由蓝牙扫描所储存的 RPI ,以判断是否曾经近距离接触过。

依据保障隐私性的原则,判断结果由用户自行管理,不会被直接上传至诊断服务器。

图6:不同秘钥之间的生成关系 [5]

针对Contact Detection Service的蓝牙广播以及扫描行为继续说明如后。

 Contact Detection Service 的蓝牙广播行为说明

为了让不同的用户记录接触史,用户的蓝牙设备(通常为手机)会定期发送具备以下特性的蓝牙广播报文。

  • 广播报文的型别为 Non-connectable Undirected ,他方在接收之后无法建立连线 

  • 广播地址的型别为 Random 

  • Non-resolvable 为避免被他人追踪,当 Rolling Proximity Identifier 改变时,广播地址也必须同时改变 

  • 广播周期建议介于200至270毫秒

图7:低功耗蓝牙的广播行为 [5]

 Contact Detection Service 的蓝牙扫描行为说明

为了更好的记录接触史,用户的手机会还定期进行具备以下特性的蓝牙广播扫描:

  • 用户用于扫描的 Scan Interval 及 Scan Window 必须满足能于5分钟内收集完邻近区域所有的 Contact Detection Service 广播报文 

  • 用户会将发现过的 Contact Detection Service 广播报文储存至设备中 

  • 扫描的结果会再加上时间戳以及 RSSI 作为后续处理的输入

图8:低功耗蓝牙的扫描行为 [5]

 官方文档关于隐私性的保障说明

  • 秘钥的生成完全由操作系统控制,避免其他应用可以直接获取任何静态秘钥信息或是对即将生成的秘钥进行预测 

  • 在不具有每日追踪密钥的情形下 RPI 与用户身份无法直接对应,可以有效降低广播 RPI 的隐私性风险 

  • 诊断服务器的运营方无方直接利用每日追踪密钥得知用户身份,诊断服务器的运营方禁止保存任何跟上传用户相关的元数据 (Metadata) 

  • 以现今的技术,要透过逆向工程假造出一把具16字节,且能产生特定RPI的每日追踪密钥几乎不可能,足以避免常见的重放攻击、假造攻击等干扰方式 

  • 每日追踪密钥的有效期只有24小时,无法用于长期追踪特定用户广播的 RPI 

四、结语

疫情自年初发展至今,已经有包括新加坡 [7] 、法国 [8] 、英国 [9] 等政府希望透过蓝牙来防堵 COVID-19 扩散,但受限于手机操作系统本身对APP的隐私管控政策,以及后台保活限制、对其它功能的影响等 [10] ,相关APP尚无法很好的展开推广。

无独有偶的,蓝牙联盟目前也有一个相关的 Digital Contact Tracing Service 工作项目提案正在进行立项,牵头的公司包括 Intel、Microsoft、Amazon、Samsung、Oppo 等 [10] ,这个项目看起来跟谷歌与苹果在推的 Contact Detection Service 貌似不是同一件事。截止2020年4月22日,谷歌与苹果公司皆未参与该立项联署。

据了解,谷歌与苹果公司最终的目标,是要做到直接将相关功能内置于操作系统中并将体验做到最好,用户可以直接激活而无需另外安装APP,经过审核的三方应用也将可以直接接入该功能 [12] 。

图9:用户反馈由新加坡官方所推出的TraceTogether APP会影响收听音乐的体验 [11]

然而,谷歌与苹果的如意算盘打的虽响,却未必能完美实现,毕竟,让用户愿意升级操作系统并自愿加入并不是件容易的事。

脑洞再开的大一点,如果谷歌跟苹果为了抗疫能联手合作的话,BATX等是否也可以整合生态优势,集成移动端能力推出一套类似的抗疫体系呢?毕竟现代人生活都少不了手机,每到一个地方稍微待的久一点,就会开始看微信、看钉钉、逛手淘、刷个抖音。即使没有办法做到操作系统层级的后台保活,只要巨头们能达成一致协议,也有机会利用蓝牙做到近距离接触史回溯。

参考文献

[1] 史上首次:苹果谷歌高调合作追踪新冠接触者,打通iOS和安卓,5月上线

[2] Privacy-Preserving Contact Tracing
[3] Apple and Google partner on COVID-19 contact tracing technology
[4] Privacy-safe contact tracing using Bluetooth Low Energy
[5] Contact Tracing Bluetooth Specification
[6] Contact Tracing Cryptography Specification
[7] Singapore government launches new app for contact tracing to combat spread of COVID-19
[8] France urges Apple and Google to ease privacy rules on contact tracing
[9] Governments likely to defer to Big Tech on Covid-19 contact tracing
[10] Digital Contact Tracing Service
[11] TraceTogether
[12] Coronavirus: Apple and Google team up to contact trace Covid-19

END

往期精彩文章回顾

长按扫描二维码关注凌云时刻

每日收获前沿技术与科技洞见

转载地址:https://lingyun.blog.csdn.net/article/details/107036605 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:美年健康俞熔:创业者最重要的是锻造内心、熬过拐点 | 凌云时刻
下一篇:疫情防控的“第二战场” | 凌云时刻

发表评论

最新留言

关注你微信了!
[***.104.42.241]2024年04月25日 14时34分35秒

关于作者

    喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!

推荐文章