Giter VIP home page Giter VIP logo

cwa-dcc-server's Introduction

Corona-Warn-App Testresult Server

DevelopmentDocumentationSupportContributeContributorsRepositoriesLicensing

The goal of this project is to develop the official Corona-Warn-App for Germany based on the exposure notification API from Apple and Google. The apps (for both iOS and Android) use Bluetooth technology to exchange anonymous encrypted data with other mobile phones (on which the app is also installed) in the vicinity of an app user's phone. The data is stored locally on each user's device, preventing authorities or other parties from accessing or controlling the data. This repository contains the testresult server for the Corona-Warn-App.

Status

ci quality gate coverage bugs

About this component

In the world of the Corona Warn App the Test Result Server receives the results from laboratories and delivers these results to the app via the verification-server. The parts of the verification component cooperate in the following manner:

  • The Verification Server of the Corona Warn App (repository: cwa-verification-server) helps validating whether upload requests from the mobile App are valid or not.
  • The Verification Portal of the Corona Warn App (repository: cwa-verification-portal) allows hotline employees to generate teleTANs which are used by users of the mobile App to upload their diagnostic keys.
  • The Verification Identity and Access of the Corona Warn App (repository: cwa-verification-iam) ensures that only authorized health personnel get access to the Verification Portal.
  • The Test Result Server of the Corona Warn App (repository: cwa-testresult-server) receives the results from laboratories and delivers these results to the app via the verification-server.

So, this component receives the test results of COVID-19 Tests from connected laboratories. The information submitted by the laboratories contains an UUID and the result.

Development

This component can be locally build in order to test the functionality of the interfaces and verify the concepts it is build upon.
There are two ways to build:

  • Maven build - to run this component as spring application on your local machine
  • Docker build - to run it as docker container build from the provided docker build file

Prerequisites

Open JDK 11
Maven
(optional): Docker

Build

Whether you cloned or downloaded the 'zipped' sources you will either find the sources in the chosen checkout-directory or get a zip file with the source code, which you can expand to a folder of your choice.

In either case open a terminal pointing to the directory you put the sources in. The local build process is described afterwards depending on the way you choose.

Maven based build

For actively take part on the development this is the way you should choose.
Please check, whether following prerequisites are fulfilled

is installed on your machine.
You can then open a terminal pointing to the root directory of the verification server and do the following:

mvn package
java -jar target/cwa-testresult-server-*.jar  

The verification server will start up and run locally on your machine available on port 8080.

Docker based build

We recommend that you first check the prerequisites to ensure that

is installed on you machine

On the commandline do the following:

docker build -f|--file <path to dockerfile>  -t <imagename>  <path-to-testresultserver-root>
docker run -p 127.0.0.1:8080:8080/tcp -it <imagename>

or simply

docker build --pull --rm -f "Dockerfile" -t cwa-testresultserver "."
docker run -p 127.0.0.1:8080:8080/tcp -it cwa-testresultserver

if you are in the root of the checked out repository.
The docker image will then run on your local machine on port 8080 assuming you configured docker for shared network mode.

API Documentation

Along with the application there comes an OpenApi Doc based swagger documentation which you can access in your web browser, when the test result server applications runs:

<base-url>/api/swagger

Which results in the following URL on your local machine: http://localhost:8080/api/swagger

Working Language

We are building this application for Germany. We want to be as open and transparent as possible, also to interested parties in the global developer community who do not speak German. Later on this application might also serve as a template for other projects outside of Germany. For these reasons, we decided to apply English as the primary project language.

Consequently, all content will be made available primarily in English. We also ask all interested people to use English as language to create issues, in their code (comments, documentation etc.) and when you send requests to us. The application itself, documentation and all end-user facing content will - of course - be made available in German (and probably other languages as well). We also try to make some developer documentation available in German, but please understand that focussing on the Lingua Franca of the global developer community makes the development of this application as efficient as possible.

Documentation

The full documentation for the Corona-Warn-App can be found in the cwa-documentation repository. The documentation repository contains technical documents, architecture information, and white papers related to this implementation.

Support and Feedback

The following channels are available for discussions, feedback, and support requests:

Type Channel
General Discussion
Concept Feedback
Test Result Server Issue
Other Requests

How to Contribute

Contribution and feedback is encouraged and always welcome. For more information about how to contribute, the project structure, as well as additional contribution information, see our Contribution Guidelines. By participating in this project, you agree to abide by its Code of Conduct at all times.

Contributors

The German government has asked SAP AG and Deutsche Telekom AG to develop the Corona-Warn-App for Germany as open source software. Deutsche Telekom is providing the network and mobile technology and will operate and run the backend for the app in a safe, scalable and stable manner. SAP is responsible for the app development, its framework and the underlying platform. Therefore, development teams of SAP and Deutsche Telekom are contributing to this project. At the same time our commitment to open source means that we are enabling -in fact encouraging- all interested parties to contribute and become part of its developer community.

Repositories

A list of all public repositories from the Corona-Warn-App can be found here.

Licensing

Copyright (c) 2020-2023 Deutsche Telekom AG.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.

You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the LICENSE for the specific language governing permissions and limitations under the License.

cwa-dcc-server's People

Contributors

ascheibal avatar bergmann-dierk avatar daniel-eder avatar dependabot[bot] avatar ein-tim avatar f11h avatar mschulte-tsi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cwa-dcc-server's Issues

Implement Endpoint to Download DCC by QuickTest Backend

The QuickTest Backend needs an endpoint to download successfuly created DCC documents.

Endpoint
Reachable from: Within OS Cluster
Method: POST
Path: /version/v1/dcc
Body:

{
  "testId": {{testId}}
}

Response:
200:

{
  "dcc": {{base64 encoded DCC with encrypted payload}}
}

202: DCC is pending
400: Invalid format (e.g. Invalid testId format, No PublicKey assigned to RegistrationToken)
404: TestId does not exists
410: DCC already cleaned up
412: TestResult not yet received
500: Failure when processing DCC --> SIGNING_CLIENT_ERROR, SIGNING_SERVER_ERROR, LAB_NOT_SUPPORTED, LAB_NOT_REACHABLE, LAB_INSUFFICIENT_DATA, INTERNAL

Das "technische Ablaufdatum" wird aktuell bei den Schnelltestzertifikaten auf 24Stunden gesetzt, selbst wenn die Zertifikate bei der Einreise 48h oder 72h gültig sind.

Das "technische Ablaufdatum" der aktuell in Deutschland ausgestellten Schnelltestzertifikate, wird aktuell bei den Schnelltestzertifikaten auf 24Stunden gesetzt. In den CovicCheck Apps, auch der französischen, führt das dazu, dass das Zertifikat nach 24h als nicht mehr Gültig angesehen wird.
Selbst wenn z.B. in Frankreich zur Einreise ein Schnelltest 72h alt sein darf, zeigen die deutschen und auch die französische App diesen Test als "Abgelaufen an.

Lösung: Entweder die Technische Gültigkeit der Testzertifikate auf mindestens 1 Woche setzen (bevorzugt, da diese Änderung nur bei der Zertifikatserstellung gemacht werden muss).
oder alle Apps müssen das "Technische Ablaufdatum" für Testzertifikate ignorieren.

Um die ursprüngliche Idee des "Technischen Ablaufdatums" zu erhalten, macht nur Variante 1 wirklich Sinn. Das technische Ablaufdatum soll definieren, ab wann ein Zertifikat nicht mehr gültig ist, aber nicht, ab wann der durchgeführte Test nicht anerkannt werden darf, denn das ist je Land/Bundesland/Verwendungszweck unterschiedlich und volatil.

Das "Technische Ablaufdatum" muss völlig losgelöst von der Aktzeptanzzeit des Schnelltestergebnisses sein. Dieses Datum ist auch ursprünglich für den Impf/Genesenennachweis gedacht gewesen.

Der aktuelle Zustand ist fatal, da er aktuell viele Reisende vor Probleme stellt und verunsichert. Insbesondere da gültige Testzertifikate von den Apps als ungültig bzw. abgelaufen angezeigt werden.

Add Info Logging Messages to DEBUG Messages

For monitoring purpose we need to add new Log messages to all DEBUG messages. The new Log messages should be of Level INFO and placed next to DEBUG messages. But without private data.

Create Project Structure

We need to setup the Spring Boot Project for the CWA-DCC-Server.
This task can be done based on the CWA-Verification-Server

AK:

  • Setup Project without Controllers
  • Setup CI

Define and Implement Endpoint to upload DCC by Lab

The Test-Lab Servers need an endpoint to upload created DCC components.

Endpoint
HTTP-Method: POST
Path: /version/v1/test/{testId}/dcc
Body: JSON-Object containing: Hash of DCC, Encrypted DCC, Data Encryption Key,

Responses:

201: DCC Information saved
204: DCC Information updated
404: Test does not exists
400: Invalid Data format

Progress:

  • Implementation
  • Unit-Test

Implement CleanUp Job

The database containing the DCC needs to be cleaned up automatically.

What needs to be done:

  • Delete PublicKeys after XX hours
  • Delete DCC after XX hours
  • Delete RegistrationToken after XX days
  • Unit Test

Implement LabId Pinning

A LabId should exclusivly used by one partner.
When a labId was used by a partner a link to the partnerId needs to be created. The amount of labIds a partner can claim needs to be configurable. When a LabId <-> PartnerId is not used for a configurable amount of time it should be deleted.

Todo:

  • Implement LabId Claiming
  • Implement Cleanup
  • Implement Endpoint to manually claim LabId
  • Unit Tests

Certificate chain is incomplete

Describe the bug

The certificate chain for the productive server is not complete. For the WRU environment, the certificate chain is complete.
WRU:
https://www.ssllabs.com/ssltest/analyze.html?d=dcc-proxy-cff4f7147260.coronawarn.app&hideResults=on
PROD:
https://www.ssllabs.com/ssltest/analyze.html?d=dcc-proxy.coronawarn.app&hideResults=on

Expected behaviour

Complete certificate chain on the productive environment.

Steps to reproduce the issue

Performing an SSL check.

Alternatively, when connecting with Java, the intermediate certificate must be explicitly included in the trust store for the connection to be successful.

Technical details

Possible Fix

Adaptation of the SSL configuration as in the WRU environment..

Additional context

Implement Endpoint to Download DCC by CWA

The CWA needs an endpoint to download successfuly created DCC documents.

Endpoint
Reachable from: Internet
Method: POST
Path: /version/v1/dcc
Body:

{
  "registrationToken": {{registrationToken from VerificationServer}}
}

Response:
200:

{
  "dek": {{dataEncryptionKey}},
  "dcc": {{base64 encoded DCC with encrypted payload}}
}

202: DCC is pending
400: Invalid format (e.g. Invalid RegistrationToken format)
404: RegistrationToken is not registered at DCC Server
410: DCC already cleaned up
412: TestResult not yet received
500: Failure when processing DCC --> SIGNING_CLIENT_ERROR, SIGNING_SERVER_ERROR, LAB_NOT_SUPPORTED, LAB_NOT_REACHABLE, LAB_INSUFFICIENT_DATA, INTERNAL

Progress:

  • Implementation
  • Unit-Test

Define and Implement Endpoint to get pending DCC Jobs

The Test-Lab Servers need an endpoint to check whether a DCC for a C19 Test needs to be issued. This endpoint has to response with the PublicKey which was uploaded in the step before.

Endpoint
HTTP-Method: POST
Path: /version/v1/publicKey/search
Body:

{
  "labId": "{{labID}}"
}

Responses:

  • 200: Json Array with testId, DCCI and corresponding publicKey
[
  {
    "testId": "{{testId}}",
    "dcci": "{{dcci}}",
    "publicKey": "{{publicKey}}"
  }
]

Progress:

  • Implementation
  • Unit-Test

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.