整理 | 夕颜

出品 | CSDN（ID:CSDNnews）

2020 年 5 月 21 日，GitHub Trending 榜首被一款德国疫情防控应用程序 Corona-Warn-App 夺得， 热度颇高。值得注意的是，这款 App 是基于谷歌和苹果发布 Exposure Notification API 框架，这个框架在此前国际以轻爆发阶段曾引起很多人的关注。      

按照惯例，先放上 GitHub  开源地址：

https://github.com/corona-warn-app/cwa-server

基于谷歌和苹果的 Exposure Notification API

从字面上来看，Corona-Warn-App 的意思是“新冠病毒预警 App”。看过项目介绍后我们发现，原来该项目是世界第三大独立软件供应商，全球第二大云公司为德国开发的官方新冠疫情追踪应用程序，基于苹果和谷歌的 Exposure Notification API（曝光通知 API）。这些应用程序适用于 iOS 和 Android 设备，可使用蓝牙技术与附近同样安装了该 App 的手机交换匿名的加密数据。

本项目的存储库包含用于 Corona-Warn-App（下文简称 CWA）加密密钥的服务器实现，但是实现仍在进行中，当前在 GitHub 上开源的为 alpha 代码。

看到这段介绍，有人可能要问，这里的 Exposure Notification API 是什么？其实这个方案在刚推出时就已经引发了大家关于疫情期间从技术上防疫的关注。简单来说，Exposure Notification API（曝光通知 API）是谷歌和苹果联合发布的一个新冠病毒追踪 API，基于此框架开发的 App 可以把用户分为两类，一类是受影响的用户（affected users），一类为暴露的用户（exposed users）。受影响的用户是 COVID-19 的确诊或疑似病例，而暴露的用户可能与前者有过接触。这样，当其中用户 A 被确诊时，曾经同样使用过这款 App 并与 A 安装了 App 的设备近距离接触时，用户 B 会在 A 确诊后得到通知，提醒 B 可能感染了病毒。

值得注意的是，这个 API 是基于蓝牙技术，需要打开蓝牙开关才能交换附近设备的数据。

为了加强隐私，这个 API 把谷歌和苹果定义的加密协议的重大变化考虑进来了。最初，该协议使用了两个加密密钥，一个是用户唯一的 Tracing Key，永远留在本地设备上，另一个是 Daily Tracing Key，它是基于前者生成的一个跟踪密钥。Daily Tracing Keys 用于生成 Rolling Proximity Identifiers（又称伪随机蓝牙标识符），用于检测特定的时间段内设备的距离。

理论上来说，这种方法可以让用户在自己的信息不会泄露的前提下获取新冠病毒数据，从而达到及早发现及早治疗的目的。

技术实现解析，如何实现隐私保护？

如果这样的方法果真能够既保护用户隐私，又达到疫情防控的目的，那就非常值得探讨一番了。

后端架构

CWA 服务器在 Open Shift（“ OSP”）平台上的 Kubernetes 集群中运行。其主要目的是使用户能够使用基于 Apple / Google 规范的曝光通知框架。贡献者也说明了，尽管 CWA 尽可能地符合协议规范，但并不意味着将可以实现所有功能，主要还要l考虑数据隐私和保护（DPP）问题。

Google / Apple 的最新规范：

• Google Spec（https://static.googleusercontent.com/media/www.google.com/en//covid19/exposurenotifications/pdfs/Exposure-Key-File-Format-and-Verification.pdf）

• 苹果 Spec：https://developer.apple.com/documentation/exposurenotification/setting_up_an_exposure_notification_server?changes=latest_beta

从高层次上讲，该应用程序包含两个主要部分，如下所示。

1. CWA 后端：处理诊断密钥和配置文件的提交和聚合/分发。

2. 验证后端：处理测试结果验证并发布 TAN。此后端是单独管理和部署的。这些组件的存储库将很快向社区开放。

这里概述了 CWA 后端组件，这些组件是此存储库的一部分。

CWA 完整的体系结构概述

通过这个 API 手机的数据将被本地存储在每个用户的设备上，从而防止官方或其他方访问或控制数据。基于此 App 的 CWA 收集到的其他用户的标识符以及自己的密钥（以后可用于导出标识符）都存储在Exposure Notification API 的本地安全存储中。其他应用程序无法直接访问这个安全存储，而只能通过 Exposure Notification 框架提供的接口访问。为了防止误用，其中一些接口还受到速率限制。如果用户 SARS-CoV-2 检测呈阳性，则可以通过在 App 上长传结果，并可以选择发送一个最长 14 天的近期密钥。将密钥上传到 Corona-Warn-App 后端服务器后，App 将对所有检测呈阳性的人员的密钥进行汇总。然后，所有安装了该 App 的用户都可以收到这个秘钥列表。

与其他系统整合

对象存储

所有与移动应用相关的文件都将存储在 S3 对象存储中。这些文件包括：

• 包含诊断密钥的聚合文件，这些文件以特定的时间间隔（例如每小时）进行报告

• 包含曝光密钥的每日汇总文件，分别在各天进行报告。

• 配置文件，包含曝光配置和 CWA 移动应用程序配置

• 有关可用文件/结构/等的元信息的其他文件。

每当有新文件可用时，这些文件将被推送到 S3 兼容的对象存储中。

移动应用程序将使用 CDN 来提取文件，对存储对象中的所有文件镜像为透明的代理。

验证后端

注意：验证后端设计正在讨论中，不久后可用。

从扫描 COVID-19 测试条上打印的二维码开始，直到用户被测试为阳性时上传诊断密钥为止，验证后端都会为用户提供支持。当 COVID-19 测试结果为阳性时，测试实验室将更新验证后端。由于二维码已链接到测试，因此移动应用程序将能够从验证后端以及 TAN 中获取测试阳性通知。当用户上传过去 14 天的诊断密钥时，TAN 将用作授权令牌。

因此，从 CWA 后端的角度来看，验证后端是 TAN 验证的终点。

数据存留

数据保留期限设置为 14 天。因此，所有提交日期早于 14 天的密钥都将从系统中删除。这包括持久性层，以及 CDN /对象存储发布的文件。保留机制由分发服务强制执行。

关于此 App 的更多信息，可以在 GitHub 查看：

https://github.com/corona-warn-app/cwa-server/blob/master/docs/architecture-overview.md

疫情隐私数据真的可以被保护好吗？

当前，虽然国内新冠疫情已处于疫情发展后期，但是国际上仍处于疫情发展中期，疫情追踪应用程序依然是追踪疫情强有力的手段。但是，疫情期间收集到的个人数据安全问题正在被越来越多的人关注。疫情期间在各种 App 上填报的个人隐私数据涉及几乎每个人的身份、住址、联系等私密信息，这些信息被上传到了哪里？疫情结束后会不会被删除？万一遭到攻击被泄露怎么办？很多问题都会引起人们的疑虑。

比如在德国，CWA 出现之前就已经有一款8 个欧洲国家的大学和学院，包括罗伯特·科赫研究所共同开发的疫情追踪应用程序  Coron—App，同样是基于 Exposure Notification API，使用的也与 CWA 如出一辙——蓝牙搜索技术，装有 App 的移动设备相互靠近到一定距离，就可以加密交换疫情数据。App 开发商表示收集到的数据仅会保存在本地收集中，不会产生备份，也不会上传到任何地方，而且全程免费。

但即使是这样，德国的网友也并不买账，在德国一家大型网站 br.de 上发起的一项意愿调查中，大于三分之一的德国人表示不愿意使用这个 App，理由各种各样，比如经常联系的老人不会使用智能机，蓝牙不打开等于白费劲，但更多的人担心的是数据隐私的问题，他们并不信任数据会被很好地保护，联想到现在智能应用的隐私泄露问题严重，他们并不愿意打开“潘多拉魔盒”......

通过诸如本文中介绍的技术手段，真的能保证疫情期间用户数据的安全吗？如果是你，你愿意使用这样的 App 吗？欢迎评论区留言讨论。

【End】

更多精彩推荐
☞寻找新冠“解药”：在 10^60 化合物分子空间，他们用 AI 挖掘潜在药物
☞进程全家桶，看这一篇就够了 | 原力计划
☞踢翻这碗狗粮：程序员花 7 个月敲出 eBay，只因女票喜欢糖果盒
☞我佛了！用KNN实现验证码识别，又 Get 到一招
☞如何使用 SQL Server FILESTREAM 存储非结构化数据？这篇文章告诉你
☞加密价格更新周期：看似杂乱无章，实际内藏玄机
你点的每个“在看”，我都认真当成了喜欢