德国冠状病毒应用在GitHub上的架构

PermalLink GitHub是5000多万开发人员的家园，他们一起工作，共同托管和审查代码、管理项目和构建软件。

报名。

本文档面向技术受众，并代表架构的最新状态，由于外部依赖项(例如，Apple/Google提供的框架)仍在变化，因此该状态可能还不是最终的。

图表反映当前状态，但也可能在稍后的时间点更改。技术架构建模(TAM)用于某些图。

请注意，有关各个组件、安全概念和数据保护概念的更多技术细节将在稍后提供。

假设移动电话与其用户紧密关联，我们将设备(电话、应用程序)与使用它的人(人、用户、个人)等同起来，并使用这些术语可互换。

为了减少冠状病毒的传播，有必要告知人们他们与阳性检测人员的密切接触。到目前为止，卫生部门和公民在基于人们记忆的个人对话中发现了这些联系，这导致了大量未知的联系，例如在使用公共交通时。

使用图1中集中显示的Corona-Warn-App(请参阅作用域文档)，个人可以通过移动电话跟踪其个人暴露风险。这款应用程序使用了苹果和谷歌提供的新API，名为曝光通知框架(Exposure Notification Framework)。它采用蓝牙低能耗(BLE)机制，让单个电话充当信标(不断广播要记住的临时标识符(称为滚动邻近标识符-RPI))，同时扫描其他电话的标识符(如图1右侧所示)。标识符是电话发出的ID号。为了确保隐私并防止跟踪APP用户的移动模式，这些广播的标识符只是临时的，并且不断变化。新标识符由临时暴露密钥(TEK)派生而来，该密钥通过密码学方法替代每天午夜(UTC)，这将在图10中详细说明。当TEK链接到阳性检测时，它们在技术上保持不变，但称为诊断密钥。

收集的其他用户的标识符以及自己的密钥(稍后可以用来导出标识符)被本地存储在电话上，存储在Apple和Google提供的框架的安全存储中。此安全存储不能由应用程序直接访问，只能通过暴露通知框架提供的接口进行访问。其中一些接口受到速率限制，以防止误用。如果用户的SARS-CoV-2检测呈阳性，他们可以通过提供测试验证来更新他们在应用程序中的状态，并选择发送最长14天的最近密钥的选项。一旦密钥被上传到Corona-Warn-App后端服务器，所有经过测试的人员的密钥都会被聚合。然后，所有安装了该应用程序的手机都可以使用这个按键列表。此外，框架的配置参数可供下载，因此可以对风险分数的计算进行调整(请参阅关于风险分数的部分)。一旦下载了密钥和暴露检测配置，数据就会移交给暴露通知API，该API会分析电话收集的标识符是否与感染者的标识符匹配。另外，现在可以解密和使用已经与标识符(例如，发送功率)一起广播的元数据。根据收集的数据，苹果和谷歌在暴露通知框架内为每个用户计算每个单独暴露的风险分值以及总体情况的风险分值。暴露定义为个人在单个日历日(UTC时区)的所有遭遇的聚合。出于隐私原因，无法在多天内跟踪与其他人的接触。

在这一点上需要注意的是，接触过阳性检测人员的人不是由中央实例通知的，但接触的风险是在他们的手机上本地计算的。有关暴露的信息保留在用户的手机上，不会共享。

这款应用追求两个目标：第一，支持个人找出他们是否接触过后来检测呈阳性的人，第二，通过在线系统在他们的手机上接收SARS-CoV-2检测的结果。这有助于缩短采取必要预防措施(例如减少接触和测试)之前的时间。为了防止误用，用户需要验证他们是否通过了测试，然后才能上传他们的密钥。通过这种集成方法，上传诊断密钥所需的验证不需要用户采取任何行动。他们只需向应用程序和暴露通知框架确认他们愿意分享他们的诊断密钥。如果执行测试的实验室不支持将测试结果直接以电子方式传输到用户电话，或者如果用户已决定不以电子方式传输其测试结果，也可以进行手动验证。

向应用程序报告阳性检测对于其他人了解相关暴露和潜在感染至关重要。另一方面，为了防止误用，需要在上传诊断密钥之前进行验证，这种验证主要有两种方法：第一种方法是使用Corona-Warn-App的集成功能来检索SARS-CoV-2测试的结果。通过这种集成，阳性检测结果已经得到了验证，用户同意后就可以立即上传诊断密钥。第二种选择是接收人类可读的令牌(例如数字或单词组合)，并将其作为验证提供给应用程序。此令牌称为TeleTAN。

图2和图3都说明了验证过程。图2显示了用户的交互流，而图3关注的是数据流和存储。通过引入Corona-Warn-App和集成的测试结果检索，添加到先前存在的常规流程中的内容在图2中标为蓝色。

这个预先存在的处理实验室结果的过程包括请求检测的医生也会收到结果，因此可以及时通知患者。根据法律规定(第9条IFSG)，实验室也会将检测结果通知负责的卫生当局(“Gesundheitsamt”)。在测试呈阳性的情况下，通知包括受影响患者的姓名、地址和出生日期等，以便与他们联系，并获知其测试呈阳性的影响。图2的步骤3中也表示了这一点。

参考图2中的步骤，使用该应用程序的流程如下：

步骤1：市民正在使用Corona-Warn-App(即广泛

(2)他们可以选择使用Corona-Warn-App扫描二维码(图3，步骤1)-如果用户决定不使用Corona-Warn-App的测试检索功能，他们仍然会通过前面介绍的常规渠道收到测试结果。

(3)当扫描代码时，针对验证服务器发出Web服务调用(REST)(图3，步骤2)，通过注册令牌将电话与二维码中的数据链接起来，该注册令牌在服务器上生成(图3，步骤3)并存储在电话上(图3，步骤4)。

第二步：样品被运到实验室(连同一个“Probenegleitschein”，上面有一个机器可读的二维码，以及多个其他条形码(实验室ID，样品ID))。

步骤3：一旦检测结果可用(即样品已处理完毕)，实验室本地运行的软件(实验室客户端)立即将检测结果与二维码中的GUID一起传输到实验室信息系统。实验室信息系统对GUID和测试结果进行散列。它通过REST接口提供给验证服务器。

步骤4a：在步骤1中注册通知后，用户的电话定期在验证服务器上检查测试结果是否可用(轮询，图3，步骤5-8)。这样，不需要使用外部推送服务器。如果结果可用，则会通知用户信息的可用性，并且只有在打开应用程序后，才会显示结果，以及对进一步操作的建议(有关更多详细信息，请参阅作用域文档)。

如果测试返回阳性结果，用户将被要求上传他们的密钥，以便其他人发现他们被暴露了。如果用户同意，应用程序将从验证服务器检索短期令牌(TAN)(另请参见图3，步骤6-8)。TAN与最多最近14天的诊断密钥一起上载到Corona-Warn-App服务器(图3，步骤12)。

Corona-Warn-App服务器使用TAN通过验证服务器验证提交的真实性(图3，步骤13-15)。TAN被验证服务器消耗并变为无效(图3，步骤14)。

如果Corona-Warn-App服务器收到肯定的确认，则将上传的诊断密钥存储在数据库中(图3，步骤16)。

如果请求失败，设备会收到相应的反馈，让用户知道需要重新提交数据。

关于图3和图4的注意事项：带有圆角的白框表示数据存储。为了增加安全性，使用HTTP方法POST而不是GET，因此数据(例如注册令牌或TAN)可以在正文中传输。

如前所述，用户可能已经决定不以电子方式检索测试结果，或者实验室可能不支持电子流程。在图2的步骤3中，可以看到，在这些情况下，卫生当局(“Gesundheitsamt”)直接联系患者。此外，在此对话期间，可以将TeleTAN提供给患者，该远程TAN可用于授权将诊断密钥从APP上传到Corona-Warn-App服务器(图2的步骤4b)。这一过程在图4中也是可视化的。无论何时就阳性检测结果联系患者，他们都可以选择接受远程TAN。公共卫生官员从门户服务的Web界面(图4，步骤1)检索TeleTan。该服务反过来向验证服务器(2-3)请求它。然后将远程TAN发送给警官(4-5)，由警官将其传送给患者(6)。一旦患者将TeleTAN输入APP(7)，它就使用TeleTAN从验证服务器(8-10)检索注册令牌。一旦用户确认了诊断密钥的上载，应用程序就使用注册令牌向服务器请求TAN(11-13)。服务器需要此TAN来确保允许设备进行上传。这些晒黑对用户是不可见的。在将TAN和诊断密钥上传到CORONA-WARN-App服务器(14)之后，CORONA-WARN-App服务器可以与验证服务器(15-16)验证TAN的真实性，并且在接收到确认时，将诊断密钥存储在数据库(17)中。

注册令牌的检索确保了特定电话和GUID/TeleTAN之间的耦合，从而防止其他人(即使他们具有QR码)检索测试结果和/或生成用于上传诊断密钥的TAN。在与验证服务器进行第一次连接时，在服务器上生成注册令牌并将其发送回客户端。应该在收到的信息内要求患者尽快扫描二维码，因为客户端和服务器之间的所有进一步通信都只使用注册令牌，并且只能创建一次。如果用户删除并重新安装APP，存储的注册令牌就会丢失，从而无法检索检测结果。然后，需要使用卫生当局的工作流程(通过热线)。从隐私保护的角度来看，通过苹果或谷歌的推送服务发送推送通知在这种情况下是不可接受的。即使通知中没有包括具体的检测结果，消息本身也会发出信号，表明用户已经进行了SARS-CoV-2检测。因此，取而代之的是轮询和本地通知。如果用户还决定不使用本地通知，也可以手动更新测试结果。

如果用户没有收到卫生部门的TeleTAN和/或丢失了二维码，则需要从热线取回TeleTAN，热线需要确保在发放TeleTAN之前允许用户进行上传。然后按照前面描述的那样使用它，从图4的步骤7开始。

根据来自Apple和Google(1.3)的文档的当前状态，第一组最多14个临时曝光密钥(链接到阳性检测时称为诊断密钥)需要在阳性检测结果可用且已同意上传之后上传(请参见图5中的(1))。由于当天的TEK仍可用于生成新的RPI，因此不能立即提供。如果它是在当天结束前上传的，恶意的第三方可能会使用它来生成链接到阳性测试的有效RPI。相反，一旦被新的TEK替换，它就会被上传(参见图5中的(2))。此上载在后台进行，不需要额外同意，因为框架为诊断密钥的请求提供了24小时的宽限期。

由于用户没有确认阴性测试结果的要求，因此后续几天上传诊断密钥的功能仍然是理论上的。这些上传中的每一个都可以最早在随后的每一天结束时进行(参见图5中的(3))。这将需要用户每天明确同意，可以一直进行到这个人不再被认为具有传染性，但也不会更长，因为这会导致假阳性。

到目前为止，需要从同一部手机上传两次(过去的诊断密钥和当天)：这意味着注册令牌在t之后可能不会失效

接受来自客户端的上传请求，通过验证服务器和相关的工作流验证与阳性测试的关联。(在图6左侧中央所示的“实验室结果检索和验证过程”一章中进行了说明)。

接受上传的诊断密钥，并将其(可选)与相应的传输风险级别参数(1-8的整数值)一起存储到数据库中。注意，用于上载诊断密钥的传入连接的元数据(例如IP)的传输在专用参与者中被移除，在图6中被标记为“传输元数据移除(Transport Metadata Removal)”。

定期(例如，每小时)将文件传输到存储服务(如图6底部所示)，该存储服务充当内容交付网络(CDN)的源。

这些任务如图7所示，左侧(Phone 1、Phone 2、Phone n)的每个泳道(图的垂直部分)代表一个安装了Corona-Warn-App的设备。电话1的用户已经接受了SARS-CoV-2测试(稍后结果呈阳性)。Phone 1和Phone n的用户仅使用该功能来跟踪潜在的暴露，Corona-Warn-App Server表示在后端工作的单个服务的外部画面。为了更好地理解，数据库已单独可视化。

需要注意的是，即使用户没有通过测试呈阳性，应用程序也会随机向Corona-Warn-App Server(在图7中由电话2表示)提交请求，这在服务器端很容易被忽略，但从外部看，就像用户上传了呈阳性的测试结果一样。这有助于保护由于检测结果呈阳性而实际提交其诊断密钥的用户的隐私。如果没有伪请求，则监视通信量的恶意第三方将清楚地看到，将某些内容上传到服务器的用户已被感染。使用我们的方法，不能检测到任何模式，也不能采取任何假设。

如果诊断密钥需要在提交阳性检测结果的随后几天上载，也应该在随机(虚拟)提交中表示该行为。

当它们一起发布时，给出了识别属于一起(即，属于同一用户)的临时曝光密钥的可能性-导致它们在数据库中是按顺序排列的。为了防止这种情况，聚集的文件将被混洗，例如通过在数据库侧使用随机排序，同时获取相应文件的数据。或者，按照RPI(随机的)的字典顺序返回它们也是一个有效的选项。

上述配置参数允许卫生当局根据当前流行情况动态调整移动应用程序的行为。例如，可以调整风险级别的风险分值阈值，以及来自暴露事件的单个数据如何影响整体分值。

更多信息可在Corona-Warn-App服务器、验证服务器和门户服务器的专用架构文档中找到。一旦文档可用，就会链接到这里。

数据区块的当前基本单位将是1小时。数据将按照Apple/Google指定的协议缓冲区格式进行编码(参见图8)。计划在数据块没有包含任何诊断密钥或诊断密钥太少的情况下，跳过块生成。

返回的数据需要签名，并将包含时间戳(有关详细信息，请参阅协议缓冲区文件)。使用索引端点不会增加请求的数量，因为可以在单个HTTP会话中处理这些请求。如果每小时端点没有保存所选小时的诊断密钥，则移动应用程序不需要下载它。另一方面，如果需要下载多个文件(例如，因为客户端在夜间关闭)，也可以在单个会话中处理它们。

为了保证文件的真实性，需要在服务器端使用私钥进行签名(根据API规范)，而移动应用使用公钥来验证签名。为了确保漫游质量(与其他地理区域中的服务器的协议互操作性)，计划在最终定义后转向单一的商定协议。

以RESTful格式检索数据，使数据更清晰，通过透明CDN可用(只需请求一次文件)。

如果所选参数没有可用的诊断密钥，但时间范围已过，则会显示带有时间戳和空l的签名有效负载。

..