-
David Schwarzmann authoredDavid Schwarzmann authored
encryption.mdx 28.38 KiB
---
title: Verschlüsselung
---
# Verschlüsselte Übertragung
## Einleitung
FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten (abgesehen von den für die Übermittlung zwingend notwendigen Daten, z.B. Destination-ID) 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.
Die Informationen auf dieser Seite sind relevant, wenn man:
- ein **Fachverfahren** mit FIT-Connect-Anbindung entwickelt oder aufsetzt
- einen **Onlinedienst** mit FIT-Connect-Anbindung entwickelt oder aufsetzt
### 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.
Bei FIT-Connect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard 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.
## Grundlagen zur sicheren Implementierung von FIT-Connect
### Ende-zu-Ende-Verschlüsselung
FIT-Connect basiert auf dem Ansatz von 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 sein müssen.
<img src="/images/encryption/tls-no-tls.png" alt="Ende-zu-Ende-Verschlüsselung Bedeutung" width="400" height="320" />
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.
### 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.
### 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.
<img src="/images/encryption/pki-check.png" alt="PKI-um Man-in-the-Middle zu verhindern" width="400" height="320" />
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.
## Architektur
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 antragsempfangende System (Fachverfahren / virtuelle Poststelle) verfügt über einen oder mehrere Endpunkt, an den Anträge gesendet werden (Zustellpunkt) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
Ein Antrag wird an einen Zustellpunkt (Zielort) geschickt. Diesen Zustellpunkt legt der Empfänger über die "Application Subscriber API" an. Der Absender muss die Destination-ID des Zustellpunktes kennen und kann dann Anträge über die "Application Sender API" an diese Destination-ID senden.
### Application Sender API
Der Absender muss die Destination-ID vorliegen haben und erfagt über die Application Sender API die Informationen zum Zustellpunkt. Diesen entnimmt er die Liste der möglichen Schemas und wählt eines aus. Sofern es sich um eine verschlüsselte Übertragung handelt, wählt er einen öffentlichen Schlüssel.
Derzeit muss die Destination-ID manuell vom Empfänger an den Absender übergeben werden. Dies soll in Zukunft automatisch mithilfe bestehender Mechanismen, z.B. XZufi oder DVDV passieren.
Das gewählte Schema wird in den Metadaten des Antrags (Application Metadata) eingetragen und legt die Art der Übertragung fest.
### Application Subscriber API
Über die Application Subscriber API werden die Destinations verwaltet, an die die Anträge gesendet werden. Eine Destination enthält eine Liste von Schemas, welche Formate der Empfänger akzeptiert.
Der Empfänger kann in der Destination mehrere Schemas und mehrere öffentliche Schlüssel hinterlegen. Der Absender sucht sich davon für die Übertragung ein Schema und einen öffentlichen Schlüssel aus. Es wird empfohlen, genau ein Schema und genau einen öffentlichen Schlüssel anzubieten.
Es ist geplant, dass die hinterlegten öffentlichen Schlüssel so organisiert werden, dass ein kontrolliertes Key-Rollover stattfinden kann. Dazu werden zu den Schlüsseln die Gültigkeitszeiträume ergänzt.
### Ablauf eines Antrags aus Bürger*innen-Client-Perspektive
Wenn eine Bürger*in nun einen Antrag im Web oder in einer App übermitteln möchte, läuft das in der Regel wie folgt ab:
- Bürger*in findet den passenden Antrag über einen Zuständigkeitsfinder.
- Die Applikation erhält aus dem Zuständigkeitsfinder die passende Destination-ID zum Antrag.
- Die Applikation ruft über die Sender-API die Formular und Datenstruktur, Verschlüsselungszertifikat, … ab.
- Die Applikation prüft das Verschlüsselungszertifikat.
- Die Applikation übermittelt die Antragsdaten und optional einen Public Key des Users verschlüsselt an die Sender-API und erhält dafür einen Status-Token.
- Mit dem Status-Token ruft die Applikation verschlüsselte Statusinformationen zum Antrag aus der Sender-API ab.
**TODO: add here some doc links about oauth**
## Bereitstellung eines Destination-Endpunktes
### Erstellung eines FIT-Connect-kompatiblen JSON Web Keys
JSON Web Keys sind das Austauschformat in dem kryptografische Schlüssel in FIT-Connect zwischen der Destination und dem Onlinedienst ausgetauscht werden. Die kryptografischen Anforderungen an die Keys findet man unter **TODO**. Die Keys sollten bereits dort generiert werden, wo sie am Ende eingesetzt werden. Ein unnötiges übertragen von Privat Keys zwischen Servern/Computern sollte vermieden werden. Sollte dies doch notwendig sein, so muss die Übermittlung wenn dann nur verschlüsselt erfolgen.
Im folgenden eine beispielhafte Schritt-für-Schritt-Anleitung um einen JSON-Web-Key zu generieren:
1. Lokale Generierung eines X.509 zugrundeliegenden RSA-Keys. `openssl genrsa -out fachverfahren1.meineverwaltung.de.key 4096`
2. Generierung des Zertifikatsrequests `openssl req -new -sha256 -key fachverfahren1.meineverwaltung.de.key -out fachverfahren1.meineverwaltung.de.csr`
3. Dieser Zertifikatsrequest muss nun von einer Verwaltungs-PKI signiert werden.
4. Das von der Verwaltungs-PKI signierte Zertifikat muss nun in einen JWK umgewandelt werden: … **TODO(Lilith): einfügen nachdem wir das einmal gemacht haben**
Das dabei entstandene Zertifikat muss zur dem Fachverfahren gehörende Destination hinzugefügt werden
### Anlegen eines Zustellpunktes
Ein Zustellpunkt benötigt mindestens immer ein erlaubtes Fachdaten-Schema sowie einen Verschlüsselungs- und einen Signaturkey. Diese müssen in das Format JSON Web Key konvertiert und über den Zustelldienst als JSON Web Key bereitgestellt werden.
#### Beispiel
```json
{
"publicKeys": {
"keys": [
{
"kty": "RSA",
"key_ops": ["wrapKey"],
"n": "……(Public Key)……",
"e": "AQAB",
"alg": "PS512",
"kid": "……(Key ID)……",
"x5t": "……(Fingerprint)……",
"x5c": [
"……(base64 encoded root cert)……",
"……(base64 encoded intermediate cert)……",
"……(base64 encoded cert)……"
]
},
{
"kty": "RSA",
"key_ops": ["verify"],
"n": "……(Public Key)……",
"e": "AQAB",
"alg": "PS512",
"kid": "……(Key ID)……",
"x5t": "……(Fingerprint)……",
"x5c": [
"……(base64 encoded root cert)……",
"……(base64 encoded intermediate cert)……",
"……(base64 encoded cert)……"
]
}
]
},
"schemas": [
{
"schemaSource": "none",
"mimeType": "json",
},
{ "schemaSource": "none",
"mimeType": "xml",
}
],
"destinationId": "b444a551-74af-4a98-aa65-d1ffccd385d1"
}
```
## Implementierung eines Onlinedienstes
### Abrufen der Endpunktinformationen
### Überprüfen der Json Web Keys
Die JSON Web Keys müssen vor der Verwendung im Client auf Gültigkeit geprüft werden. Das umfasst insbesondere folgende Punkte:
- Überprüfung gegen eine Certificate Revocation List und/oder einen OCSP-Endpunkt mit signierten Antworten.
- Überprüfung der Zertifikats-Kette bis zum Wurzelzertifikat (BSI).
Weitere Informationen zur Glütigkeitsprüfung finden sich im BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) und im Abschnitt "[Anforderungen an das kryptografische Material](Encryption_Key_Requirements.md)" .
### Aufbau der Übertragung
Eine Übertragung über FIT-Connect besteht aus einem Metadatensatz, optionalen Fachdaten und beliebig vielen (0-∞) Dokumenten (Anlagen). Ein Teil der Metadaten enthälten transportrelevante Informationen und werden deshalb unverschlüsselt übertragen. Alle nicht transportrelevanten Metadaten, die Fachdaten und Anlagen werden verschlüsselt übertragen.
Die Metadaten, Fachdaten und Anlagen werden gemäß dem Standard JSON Web Encryption RFC 7516) verschlüsselt. Als Datenformat für die Übertragung wird die sogenannte [JWE-Compact Serialisierung](https://tools.ietf.org/html/rfc7516#section-7.1) verwendet. Alle angehängten Dokumente müssen als Binärdateien und nicht als Strings enkodiert verschlüsselt werden.
Zur Verschlüsselung wird ein JSON Web Key mit dem Typ "wrap_key" verwendet.
#### Beispiel (Metadaten)
```json
{
"contentStructure": {
"data": {
"schema": {
"schemaSource": "none",
"mimeType": "json",
}
},
"docs": [
{
"size": 13046,
"purpose": "attachment",
"docId": "1",
"mimeType": "application/pdf"
}
]
},
"applicationId": "6f7b00f1-2f0c-46da-93c9-ca020aa1758f"
}
```
#### Beispiel (Fachdaten)
Bei der verschlüsselten Übertragung der Fachdaten und Anlagen wird der Content-Type "application/jose" (Achtung: jose, nicht json) verwendet.
Beispiel:
```text
PUT /delivery-service-beta7/sender/destinations/e1009dea-d97e-4104-b389-bf653d8bd30e/applications/6f7b00f1-2f0c-46da-93c9-ca020aa1758f/data HTTP/1.1
Content-Type: application/jose
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjM1ZTM2Nzk2LTM1NDAtNDUwMy1iYT...
eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.yTSVS7re6hZKO46aDriHrRFOyc5-
3TIIrvcKUf2qAfGdH7InufWPCrDyEnazSDI7HtOa5X2MU3iUnmmiEuP-Lef76xTPv2lmL4_lyhW5D8zq
7zbrIaIaVhtg7ekF1r9Oy9nLsEBQWLD4EWda2PfAibV7iQbOVMn1rVk4DzKtCykj5RSrH96i-lbPVFl-
Xw_E2G5XsL0gOHrdbAsjTF1h67bvh2hnojc9SH1GnlD0TlUO30n0GKLgC7tNNiLGtNrRo8ih3LUWYo-m
34Q6NGjaNTycHnWMYZzXHbIcBzYr6WLTsrB07rKXEyrHGLaRL88y2c-ACyEzpgv4qR5DAp98Su2u45ar
pfGU_7HxX4d-PLEoDfIRnh32nprarbaIesj9Ppgiu7QciWRApcyszk0a5rzZ7Dk_6-ydMfD92H2p3tdtOcFhj3XGUshVKec2nRhtCZPOMPTIjxFpozsiRetjZo9LFHzRcvr1eSS_hpteKJ3ltioY9nzt1IX2JqQm
TGtY.VGOCnGM9LEZP5mUO.LQeKj4SKqsUNsBp4ZRN_56QbS8MQ01YTzRVFStk.Z0YMEua9kvCV7LkeJH
kprA
```
# Vorgaben für kryptographische Verfahren
FIT-Connect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis des Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Verwendung von Schlüsseln gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
Zudem bietet FIT-Connect digital signierte Eingangsbestätigungen für Anträge. Die ausgestellten Signaturen werden auf Basis von [Security Event Tokens (SET)](https://tools.ietf.org/html/rfc8417) erzeugt und die dazugehörigen Schlüssel gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) implementiert.
Die [Liste der standardisierten Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) für Signaturen und Verschlüsselung mit JWE/JWS wird für die Nutzung in FIT-Connect unter Berücksichtigung der Vorgaben des BSI gemäß der Richtlinie [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) eingeschränkt. Diese Einschränkung der zu unterstützenden Algorithmen senkt die Komplexität in Implementierungen der angebundenen Systeme und erfolgte unter Berücksichtigung der praktischen Nutzbarkeit der Algorithmen durch eine breite Unterstützung in Implementierungen der Standards.
## Vorgaben für eingesetzte X.509-Zertifikate
Dem JSON Web Key zur *Verschlüsselung von Antragsdaten* muss ein für die Empfangsbehörde des Antrags signiertes X.509 Zertifikat zugrundeliegen. Dem für die *Signaturprüfung von digitalen Eingangsbestätigungen* verwendete JSON Web Key muss ein für die Behörde, die den Antrag im FIT-Connect-System zwischenspeichert oder empfängt, signiertes X.509 Zertifikat zugrundeliegen. Bei der Erstellung von Zertifikaten und der Zertifikatsprüfung sind die Regelungen und Standards aus BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) zu beachten.
Die verwendeten X.509-Zertifikate müssen der Verwaltungs-PKI entstammen. CA-Zertifikate der Zertifizierungsstellen innerhalb der Verwaltungs-PKI werden gemäß den [Vorgaben des BSI zur Verwaltungs-PKI](https://www.bsi.bund.de/VPKI) durch die Wurzelzertifizierungsstelle des BSI ausgestellt. Für Zertifikate müssen CRL Distribution Points (siehe 8.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)) oder ein OCSP-Endpunkt (siehe 8.5.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)) mit signierten Antworten nach [RFC 6125](https://tools.ietf.org/html/rfc6125) bereitstehen.
Für die den JSON Web Keys zugrundeliegenden X.509-Zertifikate gelten die folgenden kryptographischen Vorgaben:
| Feld | Inhalt | **Erläuterung** |
| -------------------- | ---------- | ------------------------------------------------------------ |
| Hashfunktion | SHA-512 | Hashfunktion, die bei der Signatur des Zertifikats verwendet werden muss. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)). |
| asym. Schlüssellänge | 4096 Bit | Länge des zugrundeliegenden RSA-Schlüssels (vgl. [BSI TR-02102-1 Tabelle 3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
| Signaturalgorithmus | RSASSA-PSS | Entspricht dem Standard beschrieben in [RFC 4056](https://tools.ietf.org/html/rfc4056) und vom BSI empfohlen in [BSI TR-02102-1 Abschnitt 5.4.1.](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
## Vorgaben zur Ver- und Entschlüsselung von Daten
### Vorgaben für JSON Web Keys zur Verschlüsselung
Eine Verschlüsselung erfolgt in FIT-Connect auf Basis des Standards JSON Web Encryption gemäß [RFC 7516](https://tools.ietf.org/html/rfc7516).
Zur Nutzung von Zertifikaten in FIT-Connect müssen diese in das JSON Web Key (JWK)-Format konvertiert werden. Das eingesetzte Zertifikat, alle Zertifikate im Zertifizierungspfad und das Wurzelzertifikat MÜSSEN dabei im Attribut `x5c` des JSON Web Key hinterlegt werden.
Die Auswahl, welcher JSON Web Key aus der Liste der zur Verfügung gestellten Keys bei der Verschlüsselung verwendet werden muss, wird anhand der `kid` (Key ID) entschieden. Deshalb MUSS im JSON Web Key eine Key-ID angegeben sein.
Der JSON Web Key muss über die folgenden Attribute gemäß [RFC 7517](https://tools.ietf.org/html/rfc7517#section-4) verfügen:
| Feld | Inhalt | **Erläuterung** |
| ------- | ----------------------------------------- | ------------------------------------------------------------ |
| kty | "RSA" | Keytype gemäß [RFC 7517, Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) |
| key_ops | ["wrapKey"] | Funktion des Keys (Verschlüsselung des symmetrischen Verschlüsselungskeys) gemäß [RFC 7517, Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3) |
| alg | "RSA-OAEP-256" | Vorgesehener Algorithmus zur Ver- und Entschlüsselung in Kombination mit diesem JWK. Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
| x5c | *Die gemäß RFC kodierte Zertifikatskette* | Zertifikatskette vom Teilnehmer:innen-Zertifikat bis zum Wurzelzertifikat einschließlich aller Zwischenzertifikate gemäß [Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7). Hinweis: Gemäß RFC muss das erste Zertifikat der hinterlegten Zertifikatskette dem Teilnehmer:innen-Zertifikat entsprechen. |
| kid | *Eindeutige ID des Keys* | Eindeutige ID zur Referenzierung des JSON Web Key gemäß [RFC 7516, Abschnitt 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6) dar. Es wird empfohlen, hierfür eine UUID gemäß [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden. |
| n | *Modulus des Public Key zum Zertifikat* | Der Modulus des Public Key gemäß [RFC 7518, Abschitt 6.3.1.1](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.1) ("Base64urlUInt" enkodiert) |
| e | "AQAB" | Der Exponent des Public Key gemäß [RFC 7518, Abschitt 6.3.1.2](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.2)) |
Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprechen:
```json
{
"kty": "RSA",
"key_ops": ["wrapKey"],
"alg": "RSA-OAEP-256",
"n": "……(Public Key)……",
"e": "AQAB",
"kid": "……(Key ID)……",
"x5t": "……(Fingerprint)……",
"x5c": [
"……(base64 encoded cert)……",
"……(base64 encoded intermediate cert)……",
"……(base64 encoded root cert)……"
]
}
```
### Algorithmen zur Verschlüsselung des Antragsinhalts mit JSON Web Encryption
Zur Verschlüsselung des eigentlichen Antragsinhalts wird ein symmetrisches Verschlüsselungsverfahren mit symmetrischem Schlüssel verwendet. Dieser symmetrische Schlüssel wird mit den asymmetrischen JSON Web Keys, die vom **Fachverfahren** generiert werden und die Verwendungsart **"wrapKey"** haben müssen, asymmetrisch verschlüsselt.
Der Content im verschlüsselten JSON Web Encryption Objekt muss mit den folgenden Methoden verschlüsselt werden:
- Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung der Formularinhalts- sowie der Metadaten ("Payload"): AES-256 mit der Betriebsart Galois/Counter-Mode (GCM) gemäß [TR-02102, Abschnitt 2.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)
- Asymmetrisches Verschlüsselungsverfahren, um den symmetrischen Schlüssel zu verschlüsseln: RSA-OAEP-256 (RSA mit Optimal Asymmetric Encryption Padding (OAEP) unter Verwendung der Mask Generation Function MGF1 und der Hashfunktion SHA-256). Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)
#### JSON Web Encryption Header
Im Header des JSON Web Encryption Objektes werden die Verschlüsselungs-Metadaten zu den verschlüsselten Inhaltsdaten übergeben. Header-Attribute werden in [RFC 7516](https://tools.ietf.org/html/rfc7516) definiert. Zu Übermittlung der verschlüsselten Daten wird das in [RFC 7516 Abschnitt 7.1](https://tools.ietf.org/html/rfc7516#section-7.1) beschriebene Verfahren "JWE Compact Serialization" verwendet.
Die folgenden Attribute müssen im JOSE-Header bei der Übertragung verschlüsselter Daten zwingend definiert sein:
| Feld | Inhalt | **Erläuterung** |
| ---- | ------------------ | ------------------------------------------------------------ |
| alg | "RSA-OAEP-256" | Asymmetrisches Verschlüsselungsverfahren, um den „Content Encryption Key“ (CEK) zu verschlüsseln, mit dem der Payload über das in „enc“ angegebene Verfahren symmetrisch verschlüsselt wurde. Hierfür wird der im Header per "kid" referenzierte öffentliche Schlüssel genutzt. Bezeichner des Algorithmus gemäß [RFC 7518, Abschnitt 4.1](https://tools.ietf.org/html/rfc7518#section-4.1). Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
| enc | "A256GCM" | Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung des Payloads. Bezeichner gemäß [RFC 7518 5.1](https://tools.ietf.org/html/rfc7518#section-5.1). Vorgabe gemäß [TR-02102, Abschnitt 2.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
| 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", der zur Verschlüsselung des symmetrischen Keys verwendet wurde. Gemäß [RFC 7516, Abschnitt 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)). Als Format der ID wird UUID nach [RFC 4122](https://tools.ietf.org/html/rfc4122) empfohlen. |
| cty | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7516, Abschnitt 4.1.12](https://tools.ietf.org/html/rfc7516#section-4.1.12) |
## Vorgaben zur Signaturerstellung und -prüfung
### Vorgaben für JSON Web Keys zur Signaturprüfung
Eine Signaturprüfung erfolgt in FIT-Connect auf Basis des Standards JSON Web Signature gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515).
Zur Nutzung von Zertifikaten in FIT-Connect müssen diese in das JSON Web Key-Format konvertiert werden. Das eingesetzte Zertifikat, alle Zertifikate im Zertifizierungspfad und das Wurzelzertifikat müssen dabei im Attribut `x5c` des JSON Web Key hinterlegt werden.
Der JSON Web Key muss über die folgenden Attribute gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515#section-4) verfügen.
| Feld | Inhalt | **Erläuterung** |
| ------- | ----------------------------------------- | ------------------------------------------------------------ |
| kty | "RSA" | Keytype gemäß [RFC 7517, Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) |
| key_ops | ["verify"] | Funktion des Keys (Prüfung von digitalen Signaturen) gemäß [RFC 7517, Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3) |
| alg | "PS512" | Vorgesehener Algorithmus zur Erstellung und Prüfung von Signaturen in Kombination mit diesem JWK. Vorgabe gemäß [BSI TR-02102-1, Abschnitt 5.4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
| x5c | *Die gemäß RFC kodierte Zertifikatskette* | Zertifikatskette vom Teilnehmer:innen-Zertifikat bis zum Wurzelzertifikat einschließlich aller Zwischenzertifikate gemäß [Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7). Hinweis: Gemäß RFC muss das erste Zertifikat der hinterlegten Zertifikatskette dem Teilnehmer:innen-Zertifikat entsprechen. |
| kid | *Eindeutige ID des Keys* | Eindeutige ID zur Referenzierung des JSON Web Key gemäß [RFC 7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4) dar. Es wird empfohlen, hierfür eine UUID gemäß [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden. |
| n | *Modulus des Public Key zum Zertifikat* | Der Modulus des Public Key gemäß [RFC 7518, Abschitt 6.3.1.1](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.1) ("Base64urlUInt" enkodiert) |
| e | "AQAB" | Der Exponent des Public Key gemäß [RFC 7518, Abschitt 6.3.1.2](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.2)) |
Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem folgenden Format entsprechen:
```json
{
"kty": "RSA",
"key_ops": ["verify"],
"alg": "PS512",
"n": "……(Public Key)……",
"e": "AQAB",
"kid": "……(Key ID)……",
"x5t": "……(Fingerprint)……",
"x5c": [
"……(base64 encoded cert)……"
"……(base64 encoded intermediate cert)……",
"……(base64 encoded root cert)……",
]
}
```
Nicht mehr verwendete JSON Web Keys für Signaturen müssen nach Ende der Verwendung weiterhin bis zum Ende ihrer Gültigkeitsdauer über den Endpunkt (bzw. die Destination-ID) abrufbar sein. Das soll sicherstellen, das auch bei bereits versendete Anträgen weiterhin der Antragsstatus verifiziert werden kann.
### Algorithmen zur Signaturerstellung
Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens gemäß [RFC 8417](https://tools.ietf.org/html/rfc8417) wird der Standard [JSON Web Signature](https://tools.ietf.org/html/rfc7515) eingesetzt.
Zur Signatur der Event Tokens verfügt der Server, der die Tokens ausstellt, über einen Signaturschlüssel. Bei der Verwaltung der Signaturschlüssel sind insbesondere die Hinweise in [BSI TR-03116-4, Abschnitt 6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.html) und [BSI TR-02102-1, Abschnitt 8](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) zu beachten. Der zu dem auf dem Server verwendeten Signaturschlüssel zugehörige Public Key muss als JSON Web Key bereitgestellt werden.
Als Algorithmus für die Signatur muss RSASSA-PSS in Verbindung mit SHA-512 eingesetzt werden. Das Entspricht dem Standard beschrieben in [RFC 7518 Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) und wird vom BSI als Signaturverfahren in [BSI TR-02102-1 Abschnitt 5.4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) empfohlen.
#### JSON Web Signature Header
Zu Übermittlung der Signatur wird das in [RFC 7515, Abschnitt 7.1](https://tools.ietf.org/html/rfc7515#section-7.1) beschriebene Verfahren "JWS Compact Serialization" verwendet.
Die folgenden Attribute müssen im JOSE-Header bei der Übertragung signierter Daten zwingend definiert sein:
| Feld | Inhalt | Erläuterung |
| ---- | ------------------ | ------------------------------------------------------------ |
| alg | "PS512" | Legt RSASSA-PSS mit SHA512 als Algorithmus für die Signatur fest. Bezeichner gemäß [RFC 7518, Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) |
| kid | *ID des Public Keys* | Die ID des JSON Web Keys mit dem Attribute "verify" aus dem von der Subscriber-API bereitgestellten Keysets, der zur Verifizierung der Signatur dient. Gemäß [RFC7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4). |
| cty | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7515, Abschnitt 4.1.10](https://tools.ietf.org/html/rfc7515#section-4.1.10) |