Änderungen der Algorithmen zum 01.10.2024, 01.04.2025 und 01.10.2025

Der BDEW hatte ursprünglich gefordert, dass ab dem 1. Oktober 2024 AES-128 GCM der einzige zulässige Algorithmus für die Inhaltsverschlüsselung von AS2- und E-Mail-Nachrichten sein soll.

Diese Frist wurde zuerst auf den 01.04.2025 und dann auf den 01.10.2025 verschoben.

Zur Zeit und bis zum 01.10.2025 sind nur die Algorithmen AES-128 CBC und AES-256 CBC erlaubt. Danach wird AES-128 GCM der einzige zulässige Algorithmus sein, diesmal ohne Übergangszeitraum. Als Begründung wurde die fehlende Interoperabilität zwischen den Krypto-Bibliotheken OpenSSL und Bouncy Castle genannt.

Die aktuellen FSS-Releases berücksichtigen nur die erste Fristverschiebung. Für die zweite Fristverschiebung gibt es noch kein Release. Die letzten Releases können trotzdem verwendet werden, allerdings sind bestimmte Konfigurationen erforderlich. Diese sind im Folgenden beschrieben.

Mögliche Releases des SecurityServers

Releases ab 2024-08-01 (2024-KW33)

Diese Releases wurden gemäß den ursprünglichen BDEW-Anforderungen und der ersten Fristverschiebung entwickelt. Bis zum 01.04.2025 wird standardmäßig AES-128 CBC für die Verschlüsselung verwendet. Ab dem 01.04.2025 wird AES-128 GCM eingesetzt. Eingehende Nachrichten, die nicht mit AES-128 GCM verschlüsselt wurden, stoßen ab dem 1. April auf den Fehler CW8.1.

Um diese Releases verwenden zu können, müssen zwei Punkte umgesetzt werden:

1. Die SecurityServer-Property content_encryption_algorithm muss auf AES128_CBC oder AES256_CBC gesetzt werden. Diese Property kann
   • in der Datei config.properties als content_encryption_algorithm=AES128_CBC
   • oder als Java-Property (JAVA_OPTS) -Dcontent_encryption_algorithm=AES128_CBC

   konfiguriert werden.

2. Im SecurityServer-Regelwerk muss eine Ausschlussregel für die Crypto-Warnung CW8.1 hinzugefügt werden. (Dokumentation)

Release 2024-06-20 (2024-KW25) oder älter

Diese Releases nutzen AES-128 CBC als Standardalgorithmus für die Inhaltsverschlüsselung ausgehender E-Mails. Sie können daher ohne Anpassung der Konfiguration betrieben werden. Spätestens zum 1. Oktober 2025 sollte jedoch ein neuerer Release installiert werden.

Ein Nachteil dieser Releases ist, dass sie AES-192 CBC als gültigen Algorithmus anerkennen, der ab dem 1. August 2024 eigentlich nicht mehr erlaubt ist.

FAQ

Muss die B2B auch aktualisiert werden?

Für die ursprünglichen Anforderungen des BDEW wurden die B2B (Version 2024-08-15) und die B2B-Admin-UI (Version 2024-08-01) veröffentlicht. Für die neuen Anforderungen ist die Installation dieser Releases nicht mehr notwendig, schadet jedoch auch nicht. Für die Formatumstellung 2024.10 sollte allerdings mindestens das B2B-Release 2024-07-08-01 (2024-KW28) installiert werden.

Nachrichten, die mit veralteten Algorithmen verschlüsselt wurden, werden abgelehnt. Wie können wir sie trotzdem empfangen?

Wenn Sie Nachrichten zulassen möchten, obwohl sie mit einem veralteten Algorithmus verschlüsselt wurden, können sie die Warnung CW8.1 mit dem Regelwerk übersteuern. Wie man eine solche Regel konfiguriert, erfahren Sie in der Dokumentation.

Wir nutzen eine eigenständige SecurityServer-Instanz nur für AS4. Muss sie ebenfalls aktualisiert oder konfiguriert werden?

Nein, die neuen Anforderungen an die Algorithmen gelten nur für die Marktkommunikation über E-Mails und AS2.

Warum werden manche Nachrichten nicht aus dem Postfach abgeholt oder werden als Spam ausgesteuert?

Bestimmte Marktpartner verschicken AES-128 GCM verschlüsselte E-Mails, die falsch aufgebaut sind und nicht entschlüsselt werden können. Im SecurityServer-Log erscheint dann die Meldung:

org.bouncycastle.cms.CMSException: Malformed content.
Caused by: java.lang.ClassCastException: class org.bouncycastle.asn1.DEROctetString cannot be cast to class org.bouncycastle.asn1.ASN1TaggedObject 
...
2024-08-05T12:36:42,452 INFO (SMimeDecrypter:290) - message does not seem to be encrypted

Der SecurityServer kann solche Nachrichten nicht entschlüsseln. Die B2B leitet solche E-Mails ins Spam-Postfach weiter.

Die E-Mails entsprechen nicht dem Internetstandard RFC-5652: als letztes Element von EnvelopedData wird DEROctetString statt DERSet verwendet.

Bitte informieren Sie den Absender, dass er die E-Mails entsprechend dem Standard erstellen soll. Eine detaillierte Fehleranalyse kann beim Support angefragt werden.