VAU-Handshake führt nur 2 von 6 vorgeschriebenen Server-Schlüssel-Prüfungen aus

Beschreibung

SignedPublicVauKeys signedPublicVauKeys;
try {
  signedPublicVauKeys = decodeCborMessageToClass(
      transferredSignedServerPublicKey, SignedPublicVauKeys.class);
} catch (Exception e) {
  throw new IllegalArgumentException(
      "Could not CBOR decode Signed Server Public Keys...", e);
}

VauPublicKeys transferredSignedServerPublicKeyList =
    signedPublicVauKeys.extractVauKeys();
checkCertificateExpired(
    transferredSignedServerPublicKeyList.getExp());
verifyClientMessageIsWellFormed(
    transferredSignedServerPublicKeyList.getEcdhPublicKey(),
    transferredSignedServerPublicKeyList);
// Proceeds directly to KEM encapsulation with unverified keys.

@JsonProperty("signature-ES256")
byte[] signatureEs256;

@JsonProperty("cert_hash")
byte[] certHash;

@JsonProperty("ocsp_response")
byte[] ocspResponse;

SignedPublicVauKeys signedPublicVauKeysClient = SignedPublicVauKeys.fromCbor(transferredSignedServerPublicKey);
VauPublicKeys transferredSignedServerPublicKeyList = signedPublicVauKeysClient.ExtractVauKeys();
KeyUtils.CheckCertificateExpired(transferredSignedServerPublicKeyList.Exp);
KeyUtils.VerifyClientMessageIsWellFormed(transferredSignedServerPublicKeyList.EcdhPublicKey, transferredSignedServerPublicKeyList);
// Proceeds directly to KEM encapsulation with unverified keys.

readonly byte[] SignatureEs256;
readonly byte[] CertHash;
readonly byte[] OcspResponse;

Anforderung                              Java       C#
----------------------------------------------------------
OCSP-Prüfung (max. 24 h)                Fehlend    Fehlend
Zertifikatskette zum TI-PKI-Root        Fehlend    Fehlend
Rollen-OID oid_epa_vau                  Fehlend    Fehlend
ES256-Signaturprüfung                   Fehlend    Fehlend
ECC/Kyber-Schlüsselformat-Validierung   Vorhanden  Vorhanden
Ablaufprüfung (exp > now)               Vorhanden  Vorhanden

Auswirkung

• Die innere VAU-Schicht ist dafür konzipiert, Patientendaten gegen die Kompromittierung von TLS-Infrastruktur außerhalb der TEE-Grenze zu schützen. Der Angriff erfordert eine Position innerhalb des TI- / Klinik-Netzwerk-Segments vor dem VAU-Endpunkt — also genau an der Grenze, gegen die die innere VAU-Schicht eigentlich härten soll.
• Aus dieser Position kann ein netzwerkpositionierter MITM Message 1 des Handshakes abfangen, eine KEM-Encapsulation mit den Schlüsseln des Clients durchführen und mit einer Message 2 antworten, die in der AEAD-Payload angreiferkontrollierte ECDH- und Kyber-Public-Keys trägt. Das Feld signatureEs256 kann beliebige Bytes enthalten.
• Da der Client weder Signatur noch Zertifikatskette, OCSP-Antwort oder Rollen-OID prüft, leitet er die Session-Keys aus den Schlüsseln des Angreifers ab. Der MITM hält dann beide Hälften der Sitzung und kann jede nachfolgende VAU-Nachricht im Klartext entschlüsseln und neu verschlüsseln: Medikationsdaten, Diagnoseberichte und Verordnungshistorie einer betroffenen Person, gelesen vom ePA-Client, in das ePA-Backend zurückgeschriebene Dokumente sowie die Autorisierungstransaktionen, die den Zugriff auf die Patientenakte steuern.

Abhilfe

Konsumenten, die eine der Bibliotheken produktiv einsetzen, sollten ein SignedPublicKeysTrustValidator-Interface ergänzen (der Name, den Ovivas Fork verwendet, eignet sich gut), das der Konstruktor von VauClientStateMachine *zwingend* vom Konsumenten verlangt. Rufen Sie es in receiveMessage2() vor der KEM-Encapsulation auf. Default-deny — wenn kein Validator bereitgestellt wird, soll der Handshake fehlschlagen, statt ohne Prüfung fortzufahren. Der Validator sollte die vollständige A_24624-01-Kette durchführen: Zertifikat per cert_hash abrufen, OCSP-Antwort validieren, Kette gegen TI-PKI-Roots prüfen, auf die Rollen-OID oid_epa_vau prüfen und die ES256-Signatur über den signierten Schlüsselblock verifizieren. Verwenden Sie den booleschen Rückgabewert von Signature.verify() (Java) bzw. VerifyData() (C#); ein verworfener Rückgabewert entspricht keiner Prüfung.

Checkliste für Betreiber

• Prüfen, ob Sie lib-vau / lib-vau-csharp ausliefern.

  Wenn Ihr ePA-Client (oder irgendein Produkt, das VAU spricht) lib-vau oder lib-vau-csharp direkt, über einen Fork oder über ein Git-Submodul einbindet, betrifft Sie die Lücke. Zwei produktiv ausgelieferte ePA-Implementierungen haben die fehlende Prüfung unverändert übernommen: med-united/epa4all (lib-vau als Git-Submodul) und oviva-ag/epa4all-client (ein Validator wurde ergänzt, aber falsch verdrahtet — siehe CVE-2026-44900).

• Einen Trust-Validator mit Default-deny ergänzen.

  Der Konstruktor von VauClientStateMachine muss verpflichtend einen SignedPublicKeysTrustValidator-Parameter erhalten, der in receiveMessage2() vor der KEM-Encapsulation aufgerufen wird. Wenn kein Validator bereitgestellt wird, muss der Handshake fehlschlagen und nicht stillschweigend fortgesetzt werden. Die Konstruktor-Signatur selbst muss geändert werden — Java: einen verpflichtenden Parameter zum bisherigen no-arg-Konstruktor hinzufügen; C#: äquivalente Änderung an VauClientStateMachine().

• Die vollständige A_24624-01-Kette umsetzen.

  Cert-Hash-Lookup, OCSP innerhalb von 24 h, Kette zum TI-PKI-Root, Rollen-OID oid_epa_vau, ES256-Signaturprüfung über den signierten Schlüsselblock. Alle sechs Prüfungen müssen erfolgreich sein, damit der Handshake fortgesetzt wird. TI-PKI-Root-Zertifikate liegen nicht im Standard-Truststore des Systems — beziehen Sie sie aus der veröffentlichten TI-PKI von gematik (gemSpec_PKI, Anhang — TI-Root-CA) und pinnen Sie sie explizit in Ihrem Validator.

• Prüfen, dass der boolesche Rückgabewert gelesen wird.

  Sowohl Javas Signature.verify() als auch C#'s VerifyData() liefern bei ungültiger Signatur false zurück, statt eine Exception zu werfen. Ein verworfener Rückgabewert entspricht stillschweigendem Pass. Der Oviva-Vorfall (CVE-2026-44900) ist genau dieser Fall.

• Den Validator mit einer gefälschten Message 2 prüfen.

  Bauen Sie einen lokalen VAU-Gegenpart, der auf Message 1 mit einer Message 2 antwortet, die wohlgeformte, aber nicht signierte öffentliche Schlüssel sowie beliebige Bytes im Feld signatureEs256 enthält. Der Client muss den Handshake ablehnen. Falls nicht, ist der Validator nicht eingehängt.

Bewertung im Detail

Referenzen

• gemSpec_Krypt — A_24624-01 (Client-Prüfung der signierten öffentlichen Server-Schlüssel)
• gematik-lib-vau-Repository (Java)
• gematik-lib-vau-csharp-Repository
• gematik-epa4all-examples (archiviert)
• Verwandt: Oviva-epa4all-client-Signaturprüfung verworfen (CVE-2026-44900)
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests