Skip to content
Snippets Groups Projects

Getting started encryption

Merged Getting started encryption
gettingStarted_encryption into main
Merged Marco Holz requested to merge gettingStarted_encryption into main
Compare
and
2 files
+ 65
− 17
Compare changes
  • Side-by-side
  • Inline
Files
2
docs/getting-started/encryption.mdx
+ 65
− 17
# Verschlüsselte Übertragung
import useBaseUrl from '@docusaurus/useBaseUrl';
Ziel von FIT-Connect ist es, ein möglichst einfaches, sicheres und klar definiertes Vorgehen zur Einreichung von Antragsdaten zu etablieren. Deshalb erfolgt eine Übertragung von Antragsdaten mit FIT-Connect ausschließlich verschlüsselt. Die Schwerpunkt Sicherheit wurde von Anfang an als integraler Bestandteil von FIT-Connect betrachtet.
FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten, abgesehen von den für die Übermittlung zwingend notwendigen Daten, eine Ende-zu-Ende-Verschlüsselung.
Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) und [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt. Bei der Implementierung der Ende-zu-Ende-Verschlüsselung MÜSSEN die [Vorgaben für kryptographische Verfahren](details/crypto.md) beachtet werden.
### Warum ist Ende-zu-Ende-Verschlüsselung wichtig?
Im Kontext von Anträgen an Behörden werden häufig höchstsensible personenbezogene Daten übermittelt.
Das Vertrauensniveau substantiell / hoch kann bei der Dokumentenübermittlung gemäß den [Vorgaben des BSI](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03107/TR-03107-1.pdf?__blob=publicationFile&v=4) durch eine Ende-zu-Ende-Verschlüsselung erreicht werden.
## Warum ist Ende-zu-Ende-Verschlüsselung wichtig?
Im Kontext von Anträgen an Behörden werden häufig höchstsensible Daten übermittelt, die im Rahmen von [Vorgaben des BSI](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03107/TR-03107-1.pdf?__blob=publicationFile&v=4) nur Ende-zu-Ende-verschlüsselt übertragen werden dürfen.
Zielsetzung von FIT-Connect ist ein möglichst einfaches, sicheres und klar definiertes Vorgehen zur Einreichung von Antragsdaten zu etablieren. Deshalb ist die verschlüsselte Übertragung von Antragsdaten ein integraler Bestandteil von FIT-Connect. Eine Übertragung von Antragsdaten erfolgt mit FIT-Connect ausschließlich verschlüsselt.
<img src="{useBaseUrl('/images/encryption/tls-no-tls.png')}" alt="Grafik zur Veranschaulichung einer Ende-zu-Ende-Verschlüsselung" width="600"/>
## Grundlagen zur sicheren Implementierung von FIT-Connect
### Ende-zu-Ende-Verschlüsselung
FIT-Connect verfolgt den Ansatz einer Ende-zu-Ende-Verschlüsselung. Das bedeutet, dass Daten immer vom Endgerät der Nutzer:in bis in die Zielbehörde bzw. das Fachverfahren asymmetrisch verschlüsselt sind.
FIT-Connect verwendet zur Absicherung der Übertragung von Antragsdaten und Antragsmetadaten eine auf asymmetrischer Kryptographie basierenden Ende-zu-Ende-Verschlüsselung. Abgesehen von denen für die Übermittlung zwingend notwendigen Daten können so nur die Zielbehörde bzw. das Ziel-Fachverfahren die Antragsdaten und Antragsmetadaten entschlüsseln und lesen. Sämtliche Daten der Nutzer:innen verlassen das Endgerät immer verschlüsselt.
<img src={useBaseUrl('/images/encryption/tls-no-tls.png')} alt="Grafik zur Veranschaulichung einer Ende-zu-Ende-Verschlüsselung" width="600" />
### Grundlagen zur sicheren Implementierung von FIT-Connect
Zur Realisierung einer Ende-zu-Ende-Verschlüsselung vom Endgerät der Anwender:in bis zum Fachverfahren einer Behörde, dürfen Daten nicht unverschlüsselt oder nur per TLS gesichert an ein Backend übermittelt und erst dort die für FIT-Connect spezifizierte Verschlüsselung angewendet werden. Sollte eine längerfristige Speicherung der Antragsdaten nötig sein, so muss diese immer clientseitig (z.B. in der IndexDB des Browsers, per Download, …) erfolgen.
#### Asymmetrische Verschlüsselung
### Zertifikate von Zustellpunkten müssen der Verwaltungs-PKI entstammen
Jeder verwendete Public Key (idR. in Form eines JSON Web Keys) muss einem digitalen Zertifikat entstammen und von einer Zertifizierungsstelle innerhalb der Verwaltungs-PKI signiert werden. JSON Web Keys müssen immer mit der komplette Zertifikatskette bis zum Wurzelzertifikat ausgeliefert werden, um clientseitig korrekt validierbar zu sein.
Die Ende-zu-Ende-Verschlüsselung von FIT-Connect wird mithilfe von asymmetrischer Kryptographie realisiert. Die Verschlüsselung wird als asymmetrisch bezeichnet, weil es für Ver- und Entschlüsselung im Gegensatz zur symmetrischer Verschlüsselung jeweils einen eigenen Schlüssel gibt. Die beiden Schlüssel bilden zusammen ein Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel.
### Kryptografisches Material muss vor der Verwendung immer geprüft werden
Die für die Verschlüsselung verwendeten JSON Web Keys müssen vor Verwendung anhand des zugehörigen Zertifikats aus der Verwaltungs-PKI auf Gültigkeit überprüft werden.
Für den Anwendungsfall der Verschlüsselung werden Nachrichten mit dem öffentlichen Schlüssel des Empfängers verschlüsselt. Dieser muss zuvor dem Sendern der Nachrichten bekannt gemacht werden.
Eingehende mit seinem öffentlichen Schlüssel verschlüsselte Nachrichten kann der Empfänger so mit seinem privaten Schlüssel entschlüsseln und lesen. Der öffentliche Schlüssel baut bildlich gesprochen einen Schutzcontainer um die Nachricht auf, die nur der zugehörige Empfänger öffnen kann, wie z. B. bei einem Briefkasten, der auch nur vom Besitzer des passenden Briefkastenschlüssels geöffnet werden kann.
<img src={useBaseUrl('/images/encryption/pki-check.png')} alt="Grafik zur Veranschaulichung der Einbindung einer PKI zur Verhinderung von Man-in-the-Middle-Angriffen" width="600" />
<img src="{useBaseUrl('/images/encryption/Briefkasten.png')}" alt="Beziehung öffentlicher und privater Schlüssel" width="600"/>
Nicht vertrauenswürdige Schlüssel dürfen nicht für die Verschlüsselung von Anträgen verwendet werden. Das soll Angriffe wie Man-in-the-middle-Attacken verhindern.
#### Herkunft und Zugehörigkeit von Schlüsseln prüfen
Wird einem Sender der öffentliche Schlüssel vom designierten Empfänger der Nachricht im Vorlauf nicht sicher und idealerweise sogar persönlich übermittelt, muss auf anderem Weg der oder die Eigentümerin eines Schlüssels ermittelt werden. Nur so kann man sicher gehen, auch dem richtigen Schlüssel zu verwenden.
Für genau so einen Fall wurden digitale Zertifikate entwickelt. Digitale Zertifikate sind nichts weiter als öffentliche Schlüssel, angereichert mit beglaubigten Informationen zu seiner Herkunft, und dem Eigentümer. Diese Beglaubigung von Schlüssel und Metainformationen erfolgt durch eine vertrauenswürdige dritte Person oder Institution - üblicherweise einer so genannten Zertifizierungstelle (CA - Certificate Authority), mithilfe seiner digitalen, für andere prüfbaren Unterschrift.
Ein so ausgestelltes Zertifikat kann dann vom Empfänger wie eine Visitenkarte vor Beginn der verschlüsselten Kommunikation verteilt werden, da es nur öffentliche, prüfbare Informationen enthält.
Bei der Nutzung von FIT-Connect werden diese Zertifikate von Zertifizierungsstellen durch die Verwaltungs-PKI ausgestellt.
Die für die Verschlüsselung verwendeten öffentlichen Schlüssel lassen sich so vor Verwendung anhand des zugehörigen Zertifikats aus der Verwaltungs-PKI auf Gültigkeit überprüfen.
<img src="{useBaseUrl('/images/encryption/pki-check.png')}" alt="Grafik zur Veranschaulichung der Einbindung einer PKI zur Verhinderung von Man-in-the-Middle-Angriffen" width="600"/>
Nicht vertrauenswürdige Schlüssel werden abgelehnt und dürfen nicht für die Verschlüsselung von Anträgen verwendet werden. Das soll Angriffe wie [Man-in-the-middle-Attacken](https://de.wikipedia.org/wiki/Man-in-the-Middle-Angriff) verhindern.
#### JSON Web Token
Die vorangegangen Grundlagen finden in FIT-Connect technisch in Form von JSON Web Token (JWT) Anwendung. Bei einem JWT handelt sich in erster Linie um ein JSON-Objekt (JavaScript Object Notation), d. h. ein Objekt in einem standardisierten, textbasierten Format, mit dem sehr einfach strukturierte Daten ausgetauscht werden können.
Je nach Anwendungsfall wird ein JWT dabei entweder als JSON Web Encryption (JWE), d. h., die Inhaltsdaten wurden verschlüsselt, oder als JSON Web Signature (JWS), d. h., die Inhaltsdaten wurden digital signiert, kodiert.
Sowohl JWS als auch JWE greifen dabei auf Compact Serialization zurück, um die Daten sparsam zu kodieren.
#### JWS Compact Serialization
JWS Compact Serialization stellt ein signiertes JWT als eine kompakte URL-sichere Zeichenkette (string) dar. Der string besteht dabei aus drei durch Punkte (.) voneinander getrennten BASE64URL kodierten Elementen:
- dem JOSE Header
- dem JWS Payload und
- der JWS Signature.
Im JOSE Header werden die kryptograpfischen Eigenschaften des JWS Token beschrieben. In den meisten Fällen sind das der verwendete Signaturalgorithmus `alg` sowie die Key-ID des Public Key, mit dem die Signatur des JWT geprüft werden kann `kid`.
```json
{
"alg": "PS512",
"kid": "dd0409e5-410e-4d98-85b6-f81a40b8d980",
}
```
Im JWS Payload werden die eigentlichen Inhaltsdaten des JWT transportiert. Hier können beliebige Daten übermittelt werden, so lange sie als ganzes mit BASE64URL kodiert sind. Beim folgenden Beispiel handelt es sich erneut um ein JSON-Object.
```json
{
"iss": "https://api.fitko.de/fit-connect/",
"iat": 1622796532,
"jti": "0BF6DBF6-CE7E-44A3-889F-82FE74C3E715",
"sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
"events": {
"https://schema.fitko.de/fit-connect/events/accept-submission": {}
},
"txn": "case:F73D30C6-8894-4444-8687-00AE756FEA90"
}
```