VAU Handshake Performs Only 2 of 6 Required Server-Key Checks

Description

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;

Requirement                          Java       C#
--------------------------------------------------------
OCSP verification (max 24 h)         Missing    Missing
Certificate chain to TI PKI root     Missing    Missing
Role OID oid_epa_vau                 Missing    Missing
ES256 signature verification         Missing    Missing
ECC/Kyber key format validation      Present    Present
Expiry check (exp > now)             Present    Present

Impact

• The inner-VAU layer was designed to defend patient data against compromise of TLS infrastructure that sits outside the TEE boundary. The attack requires a position inside the TI / Klinik-Netzwerk segment in front of the VAU endpoint — exactly the boundary the inner-VAU layer was specifically designed to harden against.
• From that position, a network MITM can intercept handshake Message 1, perform KEM encapsulation with the client's keys, and respond with a Message 2 carrying attacker-controlled ECDH and Kyber public keys in the AEAD payload. The signatureEs256 field can be filled with arbitrary bytes.
• Because the client never verifies the signature, certificate chain, OCSP response, or role OID, it derives session keys from the attacker's keys. The MITM then holds both halves of the session and can decrypt and re-encrypt every subsequent VAU message in clear: a patient's medication records, diagnostic reports, and prescription history read by the ePA client, documents written back to the ePA backend, and the authorization transactions that control who has access to the patient's record.

Mitigation

Downstream consumers that ship either library in a production deployment should add a SignedPublicKeysTrustValidator interface (the name Oviva's fork uses works well) which the VauClientStateMachine constructor *requires* the consumer to supply. Call it from receiveMessage2() before KEM encapsulation. Default to deny — if no validator is provided, fail the handshake rather than proceed without verification. The validator should perform the full A_24624-01 chain: fetch the certificate by cert_hash, validate the OCSP response, verify the chain against TI PKI roots, check for the oid_epa_vau role OID, and verify the ES256 signature over the signed key block. Use the boolean return value of Signature.verify() (Java) / VerifyData() (C#); a discarded return value is the same as no check at all.

Defender's Checklist

• Identify whether you ship lib-vau / lib-vau-csharp.

  If your ePA client (or any product that speaks VAU) embeds lib-vau or lib-vau-csharp directly, via a fork, or via a git submodule, the gap applies. Two shipping ePA implementations inherited the missing verification unchanged: med-united/epa4all (lib-vau as a git submodule) and oviva-ag/epa4all-client (a validator was added but wired incorrectly — see CVE-2026-44900).

• Add a trust validator with default-deny.

  Require the VauClientStateMachine constructor to take a SignedPublicKeysTrustValidator parameter and call it in receiveMessage2() before KEM encapsulation. If no validator is provided, fail the handshake; do not silently proceed. The constructor signature itself must change — Java: add a required parameter to the existing no-arg constructor; C#: equivalent change to VauClientStateMachine().

• Implement the full A_24624-01 chain.

  Cert-hash lookup, OCSP within 24 h, chain to TI PKI root, oid_epa_vau role OID, ES256 signature verification over the signed key block. All six checks must succeed for the handshake to continue. TI PKI root certificates are not in the standard system trust store — source them from gematik's published TI PKI (gemSpec_PKI, Appendix — TI Root CA) and pin them explicitly in your validator.

• Verify the boolean is read.

  Both Java's Signature.verify() and C#'s VerifyData() return a boolean for a bad signature rather than throwing. A discarded return value is a silent pass. The Oviva incident (CVE-2026-44900) is exactly this.

• Audit your verifier with a forged Message 2.

  Stand up a local VAU peer that responds to Message 1 with a Message 2 containing well-formed but unsigned public keys and arbitrary signatureEs256 bytes. The client must refuse the handshake. If it doesn't, the validator is not wired in.

Severity Reasoning

References

• gemSpec_Krypt — A_24624-01 (Client verification of server's signed public keys)
• gematik lib-vau (Java) Repository
• gematik lib-vau-csharp Repository
• gematik epa4all-examples (archived)
• Related: Oviva epa4all-client signature-verify discard (CVE-2026-44900)
• Related: ePA-VAU Client Security overview

How We Can Help

• MDR Penetration Testing