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);

@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);

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

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 auf genau dieser Grenze: dem TI- oder Klinik-Netzwerk-Segment vor dem VAU-Endpunkt.
• 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 und den Konstruktor von VauClientStateMachine so anpassen, dass er das Interface verpflichtend entgegennimmt. Rufen Sie den Validator in receiveMessage2() vor der KEM-Encapsulation auf. Default-deny: wenn kein Validator bereitgestellt wird, soll der Handshake fehlschlagen. 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) oder 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. Ersetzen Sie den bisherigen no-arg-Konstruktor durch einen, der den Validator-Parameter verpflichtend entgegennimmt, und entfernen Sie die no-arg-Form, damit Aufrufer ohne Validator beim Kompilieren scheitern. In C# entsprechend für 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 zur 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