凯哥stack

新冠接触者追踪(三) -- 技术草案更新

往期链接

苹果和谷歌联手打造新冠接触者追踪应用?
新冠接触者追踪(二) – 苹果和谷歌的技术草案

4月10日,苹果和谷歌发布了新冠追踪技术草案后,笔者完成解读后,很快发现草案更新了,通过深入了解发现,整个方案在APP交互流程上并没有变化,只在交互的数据,以及数据生成上发生了变化,因此在前一篇「 新冠接触者追踪(二) – 苹果和谷歌的技术草案 」基础上,补充更新,本文中技术细节和部分图片来源于苹果官网发布的「 新冠追踪技术草案 」。

主要变化点

上篇文章的启发章节有一个隐私的不足是跟踪密钥TK(Tracing Key)固定,被泄漏后有重大隐私问题,本次草案更新主要针对隐私增强进行改进,如下:

  • 去掉了生成不变的跟踪密钥TK(Tracing Key)
    本次草案设计直接去掉了固定的TK(Tracing Key),每天生成随机的DTK(Daily Tracing Key),在新草案中改名为TEK(Temporary Exposure Key),每天更新一次,随机生成。

Contact Tracing Bluetooth Specification v1.1

图1: Temporary Exposure Key generate, Contact Tracing Bluetooth Specification v1.1, Apple & Google
  • 去掉了DayNumberTimeIntervalNumber,引入ENIntervalNumberEKRollingPeriod

    • EKRollingPeriod
      一天24小时中有多少个10分钟,即144。
    • ENIntervalNumber
      从Unix Epoch Time(1970年1月1日)到当前有多少个10分钟,即:

    Contact Tracing Bluetooth Specification v1.1

    图2: ENIntervalNumber, Contact Tracing Bluetooth Specification v1.1, Apple & Google

    Timestamp,1970年1月1日到当前的秒数。

  • 新增RPIK(Rolling Proximity Identifier Key)
    用于生成RPI的密钥,本次新增,使用HKDF算法通过TEK(Temporary Exposure Key)生成:

Contact Tracing Bluetooth Specification v1.1

图3: RPIK generate, Contact Tracing Bluetooth Specification v1.1, Apple & Google
  • RPI(Rolling Proximity Identifier)生成方法改变
    由原来的HMAC通过DTK生成,改为通过AES128通过RPIK生成,其中PaddedData的组成为:
    • PaddedData[0-5] = UTF-8(“EN-RPI”)
    • PaddedData[6-11] = 0x000000000000
    • PaddedData[12-15] = ENIntervalNumberj

Contact Tracing Bluetooth Specification v1.1

图4: RPI generate, Contact Tracing Bluetooth Specification v1.1, Apple & Google
  • 新增AEMK(Associated Encrypted Metadata Key)
    通过TEK生成,用于加密MetaData,生成方法如下:

Contact Tracing Bluetooth Specification v1.1

图5: AEMK generate, Contact Tracing Bluetooth Specification v1.1, Apple & Google
  • 新增AEM(Associated Encrypted Metadata)
    通过AEMK加密Metadata得到,在APP收到诊断密钥后,确认有接触时使用。

Contact Tracing Bluetooth Specification v1.1

图6: AEM generate, Contact Tracing Bluetooth Specification v1.1, Apple & Google
  • 蓝牙广播PDU增加AEM信息
    其中加密前的MetaData由4字节组成:
    • byte[0] 蓝牙版本号
    • byte[1] 记录蓝牙接收的信号强度,-127dBm到127dBm,用于计算接触距离
    • byte[2-3] 保留字段。

Contact Tracing Bluetooth Specification v1.1

图7: Metadata before encrypt, Contact Tracing Bluetooth Specification v1.1, Apple & Google
  • 诊断密钥DK变化
    诊断密钥由TEK和生成TEK时的ENIntervalNumber组成,每个APP只保留14个(14天),确诊后上报到云端,由云端推送其他使用该APP的手机,用于计算接触信息上报。

密钥生成流程

密钥生成流程如下:

Contact Tracing Bluetooth Specification v1.1

图8: Key Schedule for Exposure Notification, Contact Tracing Bluetooth Specification v1.1, Apple & Google

总结

通过改进点的分析,主要是为了加强隐私:

不再有固定的密钥保留在系统上
每天更新TEK且只保存14天
增加接触距离信息,增加准确性

参考材料
[1]: https://www.apple.com/covid19/contacttracing

凯哥stack

著作权归作者所有,禁止转载


专题:

本文发表于 2020-04-25,最后修改于 2020-04-25。

本站永久域名kaige86.com,也可搜索「 凯哥stack 」找到我。

期待关注我的 ,查看最近的文章和动态。


上一篇 « 新冠接触者追踪(二) -- 苹果和谷歌的技术草案 下一篇 » 可执行程序和共享库格式的演化史

推荐阅读

Big Image