FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten, abgesehen von den für die Übermittlung
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.
zwingend notwendigen Daten, eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis der
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.
Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516)
und [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
Die JSON Web Keys werden hierbei aber aus Zertifikaten abgeleitet und die öffentlichen Teile in einem Zustellpunkt für
Die JSON Web Keys werden hierbei aber aus Zertifikaten abgeleitet und die öffentlichen Teile in einem Zustellpunkt für die Verwendung durch ein Fachverfahren hinterlegt.
die Verwendung durch ein Fachverfahren hinterlegt. Es können mehrere JWKs hinterlegt werden, welche entweder für die
Es können mehrere JWKs hinterlegt werden, welche entweder für die Verschlüsselung oder Signaturprüfung verwendet werden können.
Verschlüsselung oder Signaturprüfung verwendet werden können.
:::note Hinweis
:::note Hinweis
Die Zertifikate und damit verbundenen JWKs müssen in regelmäßigen Intervallen rolliert werden, was sich
Die Zertifikate und damit verbundene JWKs haben eine begrenzte Gültigkeitsdauer und müssen gemäß den Vorgaben der Zertifikatsinfrastruktur in regelmäßigen Intervallen erneuert werden.
an der Gültigkeitsdauer der Zertifikate orientiert.
:::
:::
## Vorgaben für eingesetzte X.509-Zertifikate
Die Voraussetzung, damit Clients Daten verschlüsseln bzw. Signaturen prüfen können, ist ein gültiges X.509-Zertifikat
Die Voraussetzung, damit Clients Daten verschlüsseln bzw. Signaturen prüfen können, ist ein gültiges X.509-Zertifikat
aus der Verwaltungs-PKI. Bei der Erstellung von Zertifikaten und der Zertifikatsprüfung sind die Regelungen und
aus der Verwaltungs-PKI. Bei der Erstellung von Zertifikaten und der Zertifikatsprüfung sind die Regelungen und
CA-Zertifikate der Zertifizierungsstellen innerhalb der Verwaltungs-PKI werden gemäß
Weitere Vorgaben für die eingesetzten X.509-Zertifikate sind unter [Vorgaben für kryptographische Verfahren in FIT-Connect](https://docs.fitko.de/fit-connect/docs/details/crypto#vorgaben-f%C3%BCr-eingesetzte-x509-zertifikate) dokumentiert.
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
| 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) |
Ein entsprechendes Zertifikat kann über die folgenden Schritte erstellt werden:
1. Lokale Generierung eines X.509 zugrundeliegenden RSA-Keys.
Nicht alle Felder, die `openssl` hier erfragt müssen ausgefüllt werden. Jedoch sollten so viele wie
Der Ablauf der Zertifikatsbeantragung ist je nach zuständiger Registrierungsstelle unterschiedlich. Details zur Beantragung von Zertifikaten werden an dieser Stelle noch ergänzt.
möglich nach bestem Wissen ausgefüllt werden.
:::
:::
3. Dieser Zertifikatsrequest muss nun von einer Verwaltungs-PKI signiert werden. Der Ablauf ist je nach zuständiger
Verwaltungs-PKI unterschiedlich, wodurch den jeweiligen Anweisungen bzw. Schritten zur Beantragung zu folgen ist.
## Erstellung eines FIT-Connect-kompatiblen JSON Web Keys
## 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
JSON Web Keys sind das Austauschformat in dem kryptografische Schlüssel in FIT-Connect zwischen der Destination und dem
Onlinedienst ausgetauscht werden. Die Schlüssel sollten erst dort generiert werden, wo sie am Ende eingesetzt werden.
Onlinedienst ausgetauscht werden. Private Schlüssel sollten nach Möglichkeit dort generiert werden, wo sie am Ende eingesetzt werden.
Ein unnötiges Übertragen von privaten Schlüsseln zwischen Servern/Computern sollte vermieden werden. Sollte dies doch
Ein Übertragen von privaten Schlüsseln zwischen Servern/Computern sollte vermieden werden.
notwendig sein, so muss die Übermittlung nur verschlüsselt erfolgen.
Sollte dies doch notwendig sein, so muss die Übermittlung nur verschlüsselt erfolgen.
Im Folgenden eine beispielhafte Schritt-für-Schritt-Anleitung, um aus einem Zertifikat aus der Verwaltungs-PKI einen
Im Folgenden eine beispielhafte Schritt-für-Schritt-Anleitung, um aus einem Zertifikat aus der Verwaltungs-PKI einen
JSON-Web-Key zu erzeugen:
JSON-Web-Key zu erzeugen:
...
@@ -91,38 +53,3 @@ insbesondere folgende Punkte:
...
@@ -91,38 +53,3 @@ insbesondere folgende Punkte:
Weitere Informationen zur Gültigkeitsprüfung finden sich im
Weitere Informationen zur Gültigkeitsprüfung finden sich im
| 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:
