This repository has been archived by the owner on May 16, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 49
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rename Lab Server to Test Result Server
- Loading branch information
Showing
1 changed file
with
10 additions
and
46 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,10 +1,13 @@ | ||
| # Software Design Testresult Server | ||
| # Software Design Test Result Server | ||
|
|
||
| by Andreas Scheibal ([email protected]) | ||
|
|
||
| ## Introduction | ||
|
|
||
| This document describes the component Test Result Server for the System “Corona Warn App”. In the world of the Corona Warn App the Verification Server helps validating whether upload requests from the mobile App are valid or not. | ||
| This document describes the component Test Result Server for the System “Corona Warn App”. In the world of the Corona Warn App the Test Result Server holds results of medical tests for SARS-CoV-2. | ||
|
|
||
| This component was named Lab Server in earlier iterations. | ||
|
|
||
| This document links the overall system architecture. | ||
| Please keep in mind, that this document is still **work-in-progress**. | ||
|
|
||
|
|
@@ -19,14 +22,11 @@ The primary scope of the component is to provide the verification server with in | |
| The Test Result Server provides test results of SARS-CoV-2 tests in a pseudonymized form to only the verification server as it requests such information. | ||
|
|
||
|  | ||
| Figure 1: Components Testresult Server | ||
|
|
||
| - The Corona-Warn-App is a system which requests test result status and obtains proofs. | ||
| - The Corona-Warn-App Server is a system which needs to verify proof. | ||
| - The Portal Server is a system which creates and obtains proof and therefore acts as source for proof. | ||
| - The Lab Server/Laboratory Information System (LIS) is a system which acts as trusted source for proof. | ||
| Figure 1: Components Test Result Server | ||
|
|
||
| Proof is represented by a Transaction Authorization Number (TAN), which is not bound to a specific transaction. | ||
| - Lab Server Gateway: System which aggregates the test results from different labs | ||
| - Lab: is the medical facility which executes the test for SARS-CoV-2 and produces the test result | ||
| - Verification Server: The instance which creates proof certificates (TAN) for positive tested users to allow them to upload their diagnostic keys | ||
|
|
||
|
|
||
| ## Core Entities | ||
|
|
@@ -67,7 +67,7 @@ Logfiles are kept for 30 days. | |
| - **Test Center**: Facility where the user can donate a probe to be tested for SARS-CoV-2, such as hospitals or practicing doctors | ||
| - **Lab**: Facility which tests the probe of the user and produces a trusted test result on SARS-CoV-2. | ||
| - **Verification Server**: Software service which proves that a user, who is taking part in the Corona Warn App and who is willing to file his Diagnosis Keys, has been really tested positive by an established authority | ||
| - **Testresult Server**: Software service, that imports the test results provided by the Labs and stores them for further use. | ||
| - **Test Result Server**: Software service, that imports the test results provided by the Labs and stores them for further use. | ||
|
|
||
|
|
||
| ## Supported User Stories | ||
|
|
@@ -158,50 +158,14 @@ All data is deleted after 14 days. | |
| **_This chapter is still in work._** | ||
|
|
||
| ### Threats | ||
| Based on STRIDE threat modelling, the threats below are anticipated: | ||
|
|
||
| |ID| Category| Name| Definition| | ||
| | ------------- |:-------------:| -----:| -----:| | ||
| |T1| Brute Force | Brute Force teleTAN| Try to guess a teleTAN via brute force attack.| | ||
| |T2| DDoS Attack| The API is attacked by a high number of requests, leading to an outage of the service| | ||
| |T3| Code injection| The payload and/or header contain code which is executed| | ||
| |T4| | ||
| |T5| Brute force attack| By a brute force attack a client wants to guess a valid GUID to create a valid TAN| | ||
| |T6| Steal secrets from logs | | ||
| Categories follow STRIDE: | ||
| - Spoofing | ||
| - Tampering | ||
| - Repudiation | ||
| - Information disclosure (privacy breach or data leak) | ||
| - Denial of service | ||
| - Elevation of privilege | ||
|
|
||
| ### Measures | ||
|
|
||
| |ID| Threat| Name| Definition| | ||
| | ------------- |:-------------:| -----:| -----:| | ||
| |MT1|||OTC DDoD Protection Infrastructure Level| | ||
| |MT2|||Strong input parameter verification, with 100% code coverage and very high amount of testing | | ||
| |MT3|||Enforcing TLS 1.2 and above | | ||
| |MT6|T2|| Use Open Telekom Cloud Anti-DDoS | | ||
| |MT7|T3|| Strict validation of http headers, body content | | ||
| |MT9|T5|| Use Throttling @ Code Level in API implementation to reduce the possible frequency of guessing attempts | | ||
| |MT10|T5|| Detect unusual load scenario and trigger warning for operation | | ||
| |MT11|T6|| Use only POST requests to avoid logging of secrets at infrastructure components| | ||
| |MT12||| Strict input validation, all REST input parameter are validated in a strict manner| | ||
|
|
||
| ## Used cryptographic algorithms | ||
| - Hashing of GUID: SHA-256, no salt, no pepper | ||
|
|
||
| ## Complexity of secrets | ||
|
|
||
| - hashed GUID: 128 bits | ||
|
|
||
| ## Used Timeframes | ||
|
|
||
| hashed GUID | ||
| - Lifespan of TAN is 14 days | ||
|
|
||