@@ -11,34 +11,26 @@ Diese Informationen sind relevant, wenn man:
...
@@ -11,34 +11,26 @@ Diese Informationen sind relevant, wenn man:
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.
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.
Bei fitconnect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard zu etablieren. Deshalb ist richtig implementierte Krypotgraphie ein fundamentaler Standard von fitconenct.
Bei fitconnect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard zu etablieren. Deshalb ist richtig implementierte Krypotgraphie ein fundamentaler Standard von fitconenct.
## Architektur
## Grundlagen
Jedes fitconenct-System verfügt über einen Endpunkt, an den Anträge gesendet werden (Fachverfahren/Subscriber-API) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
## Vorgaben
### Grundlagen
1. Grundsätzlich muss die fitconnect-Verschlüsselung immer Ende-zu-Ende sein. Das bedeutet vom Endgerät der Nutzer*in bis in die Empfangsbehörde des Antrages.
1. Grundsätzlich muss die fitconnect-Verschlüsselung immer Ende-zu-Ende sein. Das bedeutet vom Endgerät der Nutzer*in bis in das Fachverfahren bzw. die Empfangsbehörde des Antrages.
Es ist nicht vorgesehen, das Antragsdaten unverschlüsselt von einem Endgerät einer Nutzer*in an ein Backend weitergeleitet werden, um dann von dort verschlüsselt per fitconnect an die Empfangsbehörde gesendet zu werden. Antragsdaten dürfen nicht in einem Backend gespeichert werden. Sollte eine längerfristige Speicherung der Antragsdaten benötigt werden, so muss diese immer clientseitig (z.B. in der IndexDB des Browsers, per Download, …) erfolgen.
2. Die für die Verschlüsselung verwendeten JSON Web Keys müssen signiert werden, über eine Verwaltungs-PKI verifizierbar sein und auch durch den verschlüsselnden Client vollständig mit Hilfe der Verwaltungs-PKI verfiziert werden.
<imgsrc="../../assets/images/encryption/pki-check.png"alt="PKI-um Man-in-the-Middle zu verhindern"width="400"height="320">
### Anforderungen an die JSON Web Keys
Es ist nicht vorgesehen nicht vertrauenswürdige Schlüssel für die Verschlüsselung von Anträgen zu verwenden. Das soll Angriffe wie Man-in-the-middle-Attacken erschweren.
Unter Berücksichtigung der Vorgaben des BSI in der Richtlinie [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) wurden die [Liste der möglichen Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) eingeschränkt.
- Asymmetrisches Verschlüsselungsverfahren, um den "Content Encryption Key" zu verschlüsseln ("alg"): "RSA-OAEP-256"
- Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung des Payloads ("enc"): "A128GCM" oder "A256GCM"
3. Der Json Web Key muss immer die komplette Zertifikatskette bis zur Root-CA enthalten, um clientseitig korrekt validierbar zu sein.
Kern von FIT-Connect ist der Zustelldienst, der über die beiden APIs "Application Sender API" und "Application Subscriber API" den Absender (Sender) und Empfänger (Subscriber) eines Antrags verbindet.
Kern von FIT-Connect ist der Zustelldienst, der über die beiden APIs "Application Sender API" und "Application Subscriber API" den Absender (Sender) und Empfänger (Subscriber) eines Antrags verbindet.
Jedes fitconenct-System verfügt über einen Endpunkt, an den Anträge gesendet werden (Fachverfahren/Subscriber-API) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
@@ -118,7 +118,7 @@ Im Header des JSON Web Encryption Objektes werden die Metadaten zu den verschlü
...
@@ -118,7 +118,7 @@ Im Header des JSON Web Encryption Objektes werden die Metadaten zu den verschlü
| zip | DEF | Der Komprimieriungsalgorithmus für die Inhaltsdaten nach [RFC 7516 Abschnit 4.1.3](https://tools.ietf.org/html/rfc7516#section-4.1.3) |
| zip | DEF | Der Komprimieriungsalgorithmus für die Inhaltsdaten nach [RFC 7516 Abschnit 4.1.3](https://tools.ietf.org/html/rfc7516#section-4.1.3) |
| kid | ID des Public Keys | Die ID des JSON Web Keys mit dem Attribute "wrapKey", aus dem von der Subscriber-API bereitgestellten Keysets, der zur Verschlüsselung des unter enc verschlüsselten symmetrischen Keys verwendet wurde. (siehe [RFC 7516 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)) |
| kid | ID des Public Keys | Die ID des JSON Web Keys mit dem Attribute "wrapKey", aus dem von der Subscriber-API bereitgestellten Keysets, der zur Verschlüsselung des unter enc verschlüsselten symmetrischen Keys verwendet wurde. (siehe [RFC 7516 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)) |
## Signaturverfahren zur Signierung von Security Event Tokens
## Algorithmen zur Signierung von Security Event Tokens
Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens (vgl. [RFC 8417](https://tools.ietf.org/html/rfc8417)) wird das Verfahren [JSON Web Signature](https://tools.ietf.org/html/rfc7515) verwendet.
Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens (vgl. [RFC 8417](https://tools.ietf.org/html/rfc8417)) wird das Verfahren [JSON Web Signature](https://tools.ietf.org/html/rfc7515) verwendet.
