Vertrauliche Übermittlung von Antragsdaten

Um Anträge mit einem hohen Vertrauensniveau sicher zu transportieren, ist eine Verschlüsselung der Antragsdaten bis zur verantwortlichen Stelle notwendig. Hierbei sind standardisierte Vorgaben (bspw. Verschlüsselungsalgorithmen) und Formate in der XFall API verbindlich zu definieren. Diese Vorgaben sollten sich dabei an den vorhandenen Praktiken im zwischenbehördlichen Datenaustausch orientieren, um den Umsetzungsaufwand für die Beteiligten möglichst gering zu halten.

added 1 deleted label

changed the description

added 1 deleted label

added 1 deleted label and removed 1 deleted label

changed title from Ende-zu-Ende-Verschlüsselung to Vertrauliche Übermittlung von Antragsdaten

changed milestone to %beta7

added 1 deleted label and removed 1 deleted label

added 1 deleted label and removed 1 deleted label

• Best practices aus https://tools.ietf.org/html/rfc8725 übernehmen

Hyperwallet nutzt ebenfalls JOSE. Hier werden allerdings alle Daten vollständig verschlüsselt und API-Endpunkte ohne Verschlüsselung spezifiziert:

Content type for unencrypted REST request is application/json
Content type for encrypted is application/jose+json

siehe https://docs.hyperwallet.com/content/api/v3/overview/payload-encryption

Update: Hyperwallet setzt in der NodeJS-API auf https://github.com/cisco/node-jose und bietet einen Wrapper um die JOSE-Library an: [docs], [src]

Nach RFC7115 Sec. 9.2 ist application/jose für die Compact Serialization und application/jose+json für die JSON Serialization. Daher ist bei uns application/jose korrekt.

Vorschlag zum weiteren Vorgehen:

1. Die Ressourcen Create Application und List Application bilden nur Metadaten ab, die im Klartext auf dem Zustelldienst vorliegen müssen (aktuell ist hier aus meiner Sicht nur die applicationId nötig). Zusätzlich werden hier künftig nötige Parameter für die Entschlüsselung der Antragsdaten hinterlegt.
2. Die bisherigen Metadaten aus Create Application werden unter der neuen Ressource Add Application Metadata abgelegt und verschlüsselt übertragen.
3. Add Application Data, Get Application Data, Get Application Metadata, Add Application Document und Get Application Document werden nur verschlüsselt übertragen.
4. Der Endpunkt Get Destination Info wird um Parameter zur Verschlüsselung der Antragsdaten (JWK des Zielsystems) ergänzt. Die Endpunkte im Destination Management werden entsprechend um diese Infos erweitert.
5. Zur Reduktion der Komplexität und Erhöhung der Sicherheit ist eine unverschlüsselte Übertragung ist nicht mehr zulässig (plain- und base64-Encoding entfallen). Siehe #46 (closed)

API-Endpunkte werden bei dieser Lösung entweder nicht oder vollständig verschlüsselt angesprochen. Das vereinfach die Abbildung von verschlüsselten Inhalten in OpenAPI und gibt eine klare Trennung zwischen unverschlüsselten und verschlüsselten Inhalten vor.

marked this issue as related to #46 (closed)

Ja, das hier ist eine erste Umsetzung. Für die nächste Beta (8) ist geplant, dass wir ein "Envelope" aus dem Metadaten herauslösen, um die Metadaten auch zu verschlüsseln. In dem Envelope ist schon etwas mehr als nur die applicationid notwendig. Der Bereich publicServiceType und additionalReferenceInfo wären praktisch und contentStructure muss natürlich in beiden (Metadaten und Envelope) drin sein. Bei der Verschlüsselung ändern sich ja die Daten zu den Anlagen (Größe, MIME-Type, Hash, Dateiname etc.).

Ich würde diesen Ausbau gerne in einem separaten Issue tracken.

Anforderung: Daten aus Personalausweis müssen ggf. vom Server verschlüsselt werden (nicht im Browser), um Vertrauenswürdigkeit sicherzustellen (sofern diese nicht vom Authentifizierungsprovider signiert / für das antragsempfangende System authentiziert wurden). Siehe #22 (moved)

marked this issue as related to #47 (closed)

removed milestone %beta7

added 1 deleted label

added 1 deleted label

aktueller Stand der Diskussion: https://confluence.fjd.de/pages/viewpage.action?pageId=27136691

removed workflow::Peer Review label

marked this issue as related to #37 (moved)

@Marco_Holz ich kann leider den confluence link nicht anschauen. Grundsätzlich halt vor allem die frage "wo sollen die verschlüsselten Kontaktdaten liegen?". Wobei ich da noch immer die Option, das die quasi "extra Dokumente" sind sinnvoller finde. Dann vermischt man nicht encryptetet/nicht encrypted Daten und hat die Kontaktdaten explizit als Schema verlinkt.

Die Antragsmetadaten (Kontaktdaten, Payment-Daten, etc.) sollen ebenfalls vollständig verschlüsselt werden.

added 1 deleted label

removed 1 deleted label

Die API akzeptiert nur noch verschlüsselte Metadaten, dadurch ist das schon umgesetzt

closed

Was noch angepasst werden muss, sind die Content Types (application/jose statt application/json).

reopened

Warum? Der Endpunkt akzeptiert ein JSON-Dokument, welches zwei Attribute enthält, welche halt JOSE-Strings sind. Der Content-Type des Bodys bleibt ja aber JSON oder bin ich beim Falschen Endpunkt ("Submit Application")

Ah, richtig. Denkfehler. Dann sind wir hier aus meiner Sicht durch. :)

closed

changed milestone to %Submission API V1.0