Automatisierte AS4-Zertifikatsverwaltung und Krypto-Fallbacks im A²MDM Koppelpunkt-Editor

Executive Summary

Die AS4-Marktkommunikation (MaKo) stellt für deutsche Energieversorgungsunternehmen (EVU) und Messstellenbetreiber (MSB) eine kritische Infrastruktur dar. Die Cernion Energy Tools implementieren im A²MDM Koppelpunkt-Editor einen vollautomatisierten Lebenszyklus für X.509-Zertifikate im AS4-Umfeld, einschließlich proaktiver Rollover-Mechanismen, HSM-gestützter Schlüsselhinterlegung und deterministischer Krypto-Fallbacks. Der vorliegende Report dokumentiert die regulatorischen Rahmenbedingungen, die Systemarchitektur sowie die prozessualen und technischen Sicherheitsmaßnahmen, die eine unterbrechungsfreie, BDEW-konforme Kommunikation gewährleisten.

Regulatorischer Kontext (MaKo 2025)

AS4 als Pflichtprotokoll

Mit der Einführung der AS4-Profile für die Marktkommunikation (MaKo 2025) haben die Bundesnetzagentur (BNA) und die BDEW-Regelwerke eine verschlüsselte, signierte und nicht-abstreitbare Datenübertragung zwischen Marktteilnehmern zwingend vorgeschrieben. Die Kommunikation basiert auf dem OASIS ebMS 3.0 Standard mit AS4-Profil, wobei jede Nachricht sowohl auf Transport- als auch auf Payload-Ebene zertifikatsbasiert abzusichern ist.

BDEW-Vorgaben zur Krypto-Agilität

Die BDEW-Spezifikationen fordern explizit:

• Nutzung von RSA-Schlüsseln mit einer Mindestlänge von 2048 Bit (empfohlen: 4096 Bit) oder ECC mit den Kurven P-256 / P-384.
• SHA-256 als Mindesthash-Algorithmus für Signatur und Thumbprint-Bildung.
• Trennung von Signatur- und Verschlüsselungszertifikaten zur Reduktion von Angriffsflächen.
• Fristgerechter Zertifikatswechsel (Rollover) mindestens 30 Tage vor Ablauf (§ 4.2.3 BDEW AS4-Richtlinie).

Nicht-konforme Systeme riskieren den Ausschluss aus der Marktkommunikation sowie regulatorische Sanktionen nach EnWG und MaKo-Rahmenvertrag.

Anforderungen an die Betriebssicherheit

Die Betreiberverantwortung gemäß § 11 EnWG und der BSI-Grundschutz-Katalog für Energieversorgungsunternehmen (EVU) verlangen:

• Zentrale Schlüsselverwaltung in dedizierten HSMs (Hardware Security Modules) nach FIPS 140-2 Level 3 oder Common Criteria EAL4+.
• Unveränderliches Audit-Logging aller kryptografischen Operationen und Zertifikatswechsel.
• Redundante Fallback-Pfade bei Ausfall primärer Kryptografie-Provider oder HSM-Kommunikation.

Architektur des A²MDM Koppelpunkt-Editors für AS4

Entitätsmodell und Komponentenaufteilung

Der A²MDM Koppelpunkt-Editor in den Cernion Energy Tools gliedert die AS4-Zertifikatsverwaltung in folgende Entitäten:

1. AS4Endpoint: Repräsentiert den technischen Kommunikationsendpunkt (URL, PartyId, Role). Enthält Referenzen auf aktive und passive Zertifikatssätze.
2. CertificateBundle: Aggregation von Signaturzertifikat, Verschlüsselungszertifikat und zugehörigen CA-Chain-Elementen. Versioniert und mit Gültigkeitsintervall (notBefore, notAfter).
3. CryptoProfile: Konfiguration des algorithmischen Regelwerks (Signaturalgorithmus, Digest-Methode, Key-Transport, MGF). Unterstützt RSA-OAEP, RSA-PSS sowie ECDSA mit definierter Kurvenparametrisierung.
4. HSMSlot: Abstraktion eines physischen oder cloudbasierten HSM-Slots mit PKCS#11-Interface. Speichert Key-Handles, nie Private-Key-Material im Dateisystem.
5. FallbackPolicy: Regelwerk für deterministische Degradation bei HSM-Ausfall oder Krypto-Provider-Fehler.

Automatisierte Zertifikatserneuerung

Der Editor implementiert einen Event-getriebenen Renewal-Workflow:

• T-30-Tage-Trigger: Ein asynchroner Cron-Job prüft täglich die notAfter-Felder aller eingebundenen Zertifikate. Bei Unterschreitung der 30-Tage-Schwelle wird ein Renewal-Event in die Message Queue (cernion.as4.renewal) geschrieben.
• CSR-Generierung: Bei aktiviertem HSM-Modus wird ein PKCS#10-CSR über das HSM-Slot-Interface generiert; der Private Key verbleibt im HSM.
• CA-Integration: Der CSR wird an die konfigurierte interne PKI oder einen externen Trust-Center-Dienst (z. B. D-Trust, SwissSign) übermittelt. Der zurückgesandte Zertifikats-Response wird auf PKIX-Konformität (RFC 5280) und EKU-Constraints geprüft.
• Bundle-Aktivierung: Nach erfolgreicher Validierung wird das neue CertificateBundle als pending eingecheckt. Ein koordinierter Zwei-Phasen-Commit (Prep / Activate) stellt sicher, dass der Gegenstelle das neue Zertifikat vor der Aktivierung zugänglich ist (Overlap-Phase).

Krypto-Fallbacks und Provider-Redundanz

Die Architektur sieht deterministische Fallbacks vor, um den Betrieb bei HSM-Ausfall oder Provider-Inkompatibilität aufrechtzuerhalten:

• Primärer Pfad: PKCS#11-HSM über lokale HSM-Agent oder Cloud-HSM-Adapter (Thales Luna, AWS CloudHSM, IBM Cloud HSM).
• Sekundärer Pfad: Software-backed KeyStore (FIPS 140-2 validated software token), aktiv bei HSM-Timeout (> 5000 ms) oder PKCS#11-Fehlercode CKR_DEVICE_ERROR. Aktivierung erfordert explizite FALLBACK-Policy-Escalation und Alarmierung.
• Algorithmischer Fallback: Bei Nichtverfügbarkeit von RSA-OAEP mit SHA-256 auf Gegenstellen-Seite wird automatisch auf RSA-1.5 mit SHA-256 zurückgefallen, sofern die FallbackPolicy dies explizit erlaubt und die Gegenstelle im Capability-Map-Eintrag als kompatibel gelistet ist.

Alle Fallback-Ereignisse werden als SECURITY_EVENT mit Criticality HIGH protokolliert und in das SIEM der Betriebsführung gefüttert.

Handling von Zertifikatswechseln (Rollover)

Koordinierter Dual-Stack-Betrieb

Ein unkontrollierter Zertifikatswechsel führt zu Nachrichtenverwerfungen und regulatorischen Mängeln. Der A²MDM Koppelpunkt-Editor nutzt deshalb einen koordinierten Dual-Stack:

• Phase 1 – Publication: Das neue Zertifikat wird in den AS4-Metadaten (UserMessage / SignalMessage PartyInfo) als sekundäres Zertifikat annonciert, ohne dass es für die aktive Signatur oder Verschlüsselung genutzt wird. Die Gegenstelle kann das Zertifikat in ihren Trust-Store aufnehmen.
• Phase 2 – Activation Window: Zu einem definierten Zeitpunkt (typischerweise T-14 Tage vor Ablauf des alten Zertifikats) wird das neue Zertifikat primär. Das alte Zertifikat verbleibt für eingehende Nachrichten im Dekryption-KeyStore, bis es physisch abgelaufen ist (Grace Period).
• Phase 3 – Decommissioning: 24 Stunden nach notAfter des alten Zertifikats wird dieses automatisch aus dem aktiven KeyStore entfernt und in den Archiv-KeyStore (archive_keystore) überführt, wo es für historische Nachrichtendekryption für 90 Tage verfügbar bleibt (Konformität mit BSI-Anforderungen an Nachweissicherheit).

Rollover-Validierung

Vor jeder Aktivierung eines neuen Zertifikats führt das System eine 12-Punkte-Validierung durch:

1. Chain-of-Trust bis zum hinterlegten Root-CA-Zertifikat.
2. Sperrstatusprüfung via OCSP (bevorzugt) oder CRL-Distribution-Point.
3. KeyUsage- und ExtendedKeyUsage-Prüfung (Digital Signature, Key Encipherment).
4. Subject-Alternative-Name (SAN) Abgleich mit der konfigurierten PartyId.
5. Algorithmische Konformität (RSA ≥ 2048 Bit, SHA-256).
6. Gültigkeitsintervall-Plausibilisierung (nicht vor Ausstellungsdatum nutzbar, nicht nach Ablaufdatum).
7. Thumbprint-Eindeutigkeit gegenüber bestehenden Bundles.
8. HSM-Key-Handle-Verifikation (Signatur- und Dekryptionstest mit HSM).
9. Gegenstellen-Capability-Map-Abgleich (unterstützt die Gegenstelle den gewählten Algorithmus?).
10. Zeitliche Überlappung mit dem Vorgängerzertifikat (mindestens 7 Tage Overlap).
11. Metadaten-Vollständigkeit (Issuer, Serial, SKI, AKI).
12. Konformitätsprüfung gegen das BDEW AS4-Profil (spezifische OASIS-ebMS-Extensions).

Fehlerhafte Zertifikate werden abgelehnt und der Administrator über den cernion.alert.as4.renewal_failed-Kanal benachrichtigt.

Audit-Logging und Nachweisführung

Unveränderliches Protokollschema

Jede kryptografische Operation und jeder Zertifikatszustandsübergang wird in einem unveränderlichen, append-only Log persistiert. Das Schema umfasst:

• Event-Timestamp: UTC-Zeitstempel mit Millisekundenauflösung.
• Event-Type: CERTIFICATE_ISSUED, CERTIFICATE_ACTIVATED, CERTIFICATE_REVOKED, CERTIFICATE_ROLLOVER, HSM_FALLBACK_TRIGGERED, SIGNATURE_CREATED, DECRYPTION_PERFORMED, OCSP_CHECK.
• Entity-Reference: UUID des betroffenen AS4Endpoint, CertificateBundle oder HSMSlot.
• Actor: Technischer Benutzer, Prozess-ID oder Cron-Job-Identifier.
• Fingerprint: SHA-256-Thumbprint des betroffenen Zertifikats oder Schlüssels.
• Result-Code: SUCCESS, FAILURE, FALLBACK, DEFERRED.
• HSM-Audit-Token: Bei HSM-Operationen der vom HSM zurückgegebene Audit-String (z. B. Luna-Audit-Log-Referenz).
• Integrity-Hash: SHA-256 über die serialisierte Log-Zeile, verkettet mit dem vorherigen Log-Eintrag (kryptografische Verkettung).

Archivierung und Abfrage

Die Audit-Logs werden tripliziert:

1. Lokal: Geschrieben in eine Write-Ahead-Log-Struktur (WAL) im Dateisystem des A²MDM-Knotens.
2. Datenbank: In die relationale Audit-Tabelle as4_audit_log mit Indexierung über Timestamp, Entity und Event-Type.
3. Extern: Über Syslog-TLS an das zentrale SIEM der Unternehmens-IT übermittelt.

Die Aufbewahrungsfrist beträgt 10 Jahre (Anforderung nach § 257 HGB i. V. m. GoBD sowie regulatorische Anforderungen der Bundesnetzagentur). Die Abfrage erfolgt über den internen Audit-API-Endpunkt /api/as4/audit mit Zeitraum-, Entity- und Event-Filtern sowie Pagination.

Konformitätsnachweis

Im Falle einer regulatorischen Prüfung (z. B. durch die Bundesnetzagentur oder einen akkreditierten Prüfer nach MaKo) können über den Endpunkt /api/as4/audit/compliance-report strukturierte Nachweisberichte generiert werden, die enthalten:

• Vollständige Zertifikatslebenszyklus-Dokumentation pro AS4Endpoint.
• Nachweis der rechtzeitigen Erneuerung (T-30-Regel).
• Dokumentation aller Fallback-Ereignisse mit Begründung.
• HSM-Nutzungsnachweise (Key-Handle-Referenzen, kein Export von Private Keys).
• Integritätsprüfung der Log-Verkettung (Proof-of-Integrity).

Operative Redundanz und Resilienz

HSM-Hochverfügbarkeit

Die Cernion Energy Tools unterstützen den Betrieb von HSM-Clustern mit automatischem Failover. Ein konfigurierbarer Health-Check (Intervall: 30 Sekunden) prüft die Erreichbarkeit und kryptografische Funktionalität jedes HSM-Slots. Bei Ausfall eines Primär-HSMs wird der Traffic auf das Sekundär-HSM umgeleitet, ohne dass laufende AS4-Konversationen abgebrochen werden (stateless Retry mit Exponential Backoff).

Deterministische Degradation

Falls sämtliche HSM-Pfade ausfallen und die FallbackPolicy aktiviert ist, wechselt das System in den DEGRADED_MODE. In diesem Modus:

• Werden keine neuen Zertifikate ausgestellt oder aktiviert (Schreibschutz für Key-Material).
• Ausgehende Nachrichten nutzen das Software-backed KeyStore (sofern vorhanden und explizit für Degradation freigegeben).
• Eingehende Nachrichten werden weiterhin verarbeitet, sofern die Dekryptionsschlüssel verfügbar sind.
• Jede Minute wird ein Heartbeat an den operativen Leitstand (cernion.ops.degraded.heartbeat) gesendet.

Die Rückkehr in den FULL_HSM_MODE erfolgt automatisch nach erfolgreichem Health-Check und manueller Quittierung durch einen Administrator mit SECURITY_ADMIN-Rolle.

Fazit

Die automatisierte AS4-Zertifikatsverwaltung im A²MDM Koppelpunkt-Editor der Cernion Energy Tools adressiert die regulatorischen Anforderungen der MaKo 2025 und BDEW-Spezifikationen durch einen deterministischen, audit-sicheren und redundant ausgelegten Prozess. Die Kombination aus proaktivem Rollover-Management, HSM-Integration, kryptografischer Agilität und umfassendem Audit-Logging gewährleistet die Betriebskontinuität und regulatorische Konformität von Marktkommunikationsinfrastrukturen. Die vorgestellte Architektur reduziert manuelle Eingriffe, minimiert Ausfallzeiten bei Zertifikatswechseln und liefert nachprüfbare Beweisketten für behördliche Audits.