Skip to content

Commit

Permalink
Merge pull request #172 from DP-3T/release/v1.0.5
Browse files Browse the repository at this point in the history
Release/v1.0.5
  • Loading branch information
ubamrein committed Jul 9, 2020
2 parents e9b7670 + 685bc21 commit 2f8e83d
Show file tree
Hide file tree
Showing 28 changed files with 624 additions and 324 deletions.
5 changes: 4 additions & 1 deletion .github/workflows/maven.yml
Original file line number Diff line number Diff line change
Expand Up @@ -59,14 +59,17 @@ jobs:
run: mvn deploy -Dmaven.test.skip=true --file dpppt-backend-sdk/pom.xml -s $GITHUB_WORKSPACE/settings.xml
env:
GITHUB_TOKEN: ${{ github.token }}
- name: shasum
run: shasum -a 256 dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.jar > dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.sha256
shell: bash
- name: Create Snapshot Release
uses: ncipollo/release-action@v1
if: github.ref == 'refs/heads/develop'
id: create_release
with:
name: Snapshot Release ${{ github.ref }}
tag: SNAPSHOT
artifacts: "dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.jar,dpppt-backend-sdk/dpppt-backend-sdk-ws/generated/swagger/swagger.yaml"
artifacts: "dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.jar,dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.sha256,dpppt-backend-sdk/dpppt-backend-sdk-ws/generated/swagger/swagger.yaml"
body: |
Changes in this Release
- Snapshot release
Expand Down
5 changes: 5 additions & 0 deletions .github/workflows/tagged_release.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -33,11 +33,16 @@ jobs:
env:
GITHUB_TOKEN: ${{ github.token }}
TESTCONTAINERS_RYUK_DISABLED: true
- name: shasum
run: shasum -a 256 dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.jar > dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.sha256
shell: bash
- name: "Create new release"
uses: "marvinpinto/action-automatic-releases@latest"
with:
repo_token: "${{ secrets.GITHUB_TOKEN }}"
prerelease: false
files: |
dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.jar
dpppt-backend-sdk/dpppt-backend-sdk-ws/target/dpppt-backend-sdk-ws.sha256
dpppt-backend-sdk/dpppt-backend-sdk-ws/generated/swagger/swagger.yaml
2 changes: 2 additions & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,9 @@ doc: updatedoc swagger la la2 la3

updateproject:
mvn -f dpppt-backend-sdk/pom.xml install

updatedoc:
mvn -f dpppt-backend-sdk/pom.xml install -Dmaven.test.skip=true
mvn springboot-swagger-3:springboot-swagger-3 -f dpppt-backend-sdk/dpppt-backend-sdk-ws/pom.xml
cp dpppt-backend-sdk/dpppt-backend-sdk-ws/generated/swagger/swagger.yaml documentation/yaml/sdk.yaml

Expand Down
38 changes: 32 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,11 +28,33 @@ Please read the [Contribution Guide](CONTRIBUTING.md) before submitting any pull
## Introduction
This documentation describes the backend used for the SwissCovid application. It is focused on providing information for the requests used for the Exposure Notification framework. Although, code of the old format is still provided, no documentation or support is available except the code itself.

## Reproducible Builds
In order to have reproducible builds the [io.github.zlika](https://github.com/zlika/reproducible-build-maven-plugin) maven plugin is used. It replaces all timestamp with the timestamp of the last commit, and orders the entries in the JAR alphabetically. The github action then computes the sha256sum of the resulting JAR and adds the output as an build artifact.

## Dependencies
* Spring Boot 2.2.6
* Java 11 (or higher)
* Logback
* [Springboot-Swagger-3](https://github.com/Ubique-OSS/springboot-swagger3) (Github Package, plugin dependency)
* [Springboot-Swagger-3](https://github.com/Ubique-OSS/springboot-swagger3)

### GitHub Packages
Parts of the Maven build depends on artifacts, that are hosted on [GitHub Packages](https://help.github.com/en/packages). To gain access, a personal access token is required:

* Issue a personal access token from https://github.com/settings/tokens and be sure to assign the `read:packages` scope to it.
* Append the server configuration to your local Maven settings.xml, in most cases `~/.m2/settings.xml`. In the servers tag, add a child server tag with the id `github`, replacing `GITHUB_USERNAME` with your GitHub username, and `PERSONAL_ACCESS_TOKEN` with your personal access token.
```xml
...
<servers>
<server>
<id>github</id>
<username>GITHUB_USERNAME</username>
<password>PERSONAL_ACCESS_TOKEN</password>
</server>
</servers>
...
```

Please consult the [official documentation](https://help.github.com/en/packages/using-github-packages-with-your-projects-ecosystem/configuring-apache-maven-for-use-with-github-packages) for further maven specific instructions.

### Database
For development purposes an hsqldb can be used to run the webservice locally. For production systems, it is recommended to connect to a PostgreSQL dabatase (cluster if possible). There are two tables storing keys, one for the DP3T vendor independent format, one for the Google/Apple approach format. Further, to protect against JWT replay attacks a third table stores the JTI temporarily. The schemas are as following :
Expand Down Expand Up @@ -83,19 +105,23 @@ By default, the EN controller (`GaenController`) uses the base url `/v1/gaen/`.

The web-service provides three endpoints, which map the Exposure Notification specifications.

- /v1/gaen/exposed: `POST` Send a list of infected keys. If a JWT is used to authorize the request, send a JWT back to authorize the call of the following day. If the request as a whole is a "fake"-request, all keys need to be fake, otherwise a 400 HttpStatus code is returned.
- /v1/gaen/exposed: `POST` Send a list of infected keys. If a JWT is used to authorize the request, send a JWT back to authorize the call of the following day. If the request as a whole is a "fake"-request, meaning the JWT has the "fake" claim set to "1", no keys are inserted.

- /v1/gaen/exposednextday: `POST` Since the EN framework won't give the key of the current day, the upload has to be split into two. This endpoint receives the key of the last day. This endpoint eventually will be removed, as soon as the EN framework is adjusted. If JWT are activated, this endpoint needs the JWT received from a successfull request to `/v1/gaen/exposed`.

- /v1/gaen/exposed/\<timestamp\>?publishedafter=\<publishedAfter\>: `GET` Returns a list of keys, which were used at `timestamp`. Note that `timestamp` needs to be epoch milliseconds. Since the behaviour of Android and iOS aren't the same, the optional `publishedAfter` parameter is added. If set only keys, which were received *after* `publishAfter` are returned. This request returns `ZIP` file containing `export.bin` and `export.sig`, where the keys and the signature are stored, as need by the EN framework. The class for signing and serializing is `ProtoSignature`.


Further endpoints are added to the controller for debugging purposes. Those requests can e.g. be blocked by a WAF rule or similiar.

## ETag
To profit from caching e.g. when all requests are routed through a CDN, an ETag is set. The value of the ETag is the content hash of the protobuf key list. The ETag will change whenever new keys are added.
## JWT Validation
In order to prevent replay attacks, a JWT is only valid once. After one usage the "jit" claim is stored temporarily (longer than the validity).
The JWTs are validated based on the following criterias:

- JWT needs an expiresAt claim which is valid
- The expiresAt claim should not be longer than the set value in the config
- The JWT needs a "jit" claim and the said "jit" should not have been used


Note: Since we use ECDSA signatures, the signature would change each time. The same is true for the hash of the HttpPayload.

## Content Signing
In order to provide authenticity, the HttpPayload is signed. The signature is added as a `Signature` HttpHeader to each 200 or 204 response. The signature consists of a JWT containing the content hash as a claim. Further, if `protected-headers` are added in the controller (and activated through the respective key in the properties file), those headers are signed as well, thus providing the possibility of signing certain request parameters.
Expand Down
Loading

0 comments on commit 2f8e83d

Please sign in to comment.