AES-GCM Nonce Reuse in VAU Server Encryption

Description

@Override
protected long getRequestCounter() {
    return clientRequestCounter;
}

@Override
protected void checkRequestCounter(long reqCtr) {
    this.clientRequestCounter = reqCtr;
}

public byte[] encryptVauMessage(byte[] cleartext) {
    byte[] reqCtrBytes = ByteBuffer.allocate(8).putLong(getRequestCounter()).array();
    byte[] header = unionByteArrays(versionByte, puByte, reqByte, reqCtrBytes, getKeyId());
    byte[] a = new byte[4];
    new SecureRandom().nextBytes(a);
    byte[] iv = unionByteArrays(a, reqCtrBytes);
}

@Override
public byte[] encryptVauMessage(byte[] cleartext) {
    try {
      requestCounter++;
      return super.encryptVauMessage(cleartext);

protected override void CheckRequestCounter(long requestCounter)
{
    clientRequestCounter = requestCounter;
}

protected override long GetRequestCounter()
{
    return clientRequestCounter;
}

public virtual byte[] EncryptVauMessage(byte[] plaintext)
{
    long requestCounter = GetRequestCounter();
    // ...
    byte[] iv = new byte[12];
    // iv[0..4]  = random
    // iv[4..12] = requestCounter (client-supplied)
}

Messages    P(IV collision)
     100    < 0.01 %
   1,000      0.01 %
  10,000      1.16 %
  50,000     25.23 %
  77,163     50.00 %
 100,000     68.55 %

Impact

• In ePA terms, the payloads the inner-VAU layer protects include medication records, diagnostic reports, prescription history, document reads and writes, and the authorization transactions that control access to a patient's record. The two effects below apply to those payloads.
• A legitimate VAU client (or a network attacker who has completed a VAU handshake) can hold the server's IV counter portion constant by replaying a Request-Counter value, and collect server responses until two share the same 12-byte IV.
• Once two responses share the same IV, the Joux forbidden attack recovers the GHASH authentication key H. With H, the attacker can forge the GCM authentication tag for ciphertexts under any IV where a collision has been observed, enabling them to tamper with server-to-client VAU messages in a session where nonce reuse is ongoing.
• XOR of the two colliding ciphertexts yields the XOR of the two plaintexts, leaking information about ePA response payloads protected by the inner-VAU AES-GCM layer.
• Above the inner-VAU layer there is still TLS to the ePA backend, but the inner-VAU layer is the property that ePA's threat model relies on to defend patient data against compromise of TLS infrastructure that sits outside the TEE boundary. Breaking it removes that defence-in-depth boundary.
• When combined with the missing server authentication (MS-LIB-VAU-eaea8d), the attacker's position is not hypothetical. A MITM who has substituted their own keys during the handshake can pin the client Request-Counter to any fixed value on every relayed request, reducing the birthday collection from an active attack to passive observation on a channel the attacker already controls.

Mitigation

Downstream consumers that ship either library in a production deployment should add an independent serverEncryptionCounter to VauServerStateMachine (or its C# equivalent), initialise it to 0, and override encryptVauMessage() to increment that counter before encryption. A getRequestCounter() override alone is not sufficient — super.encryptVauMessage() uses that return value for both the IV and the header, so the server must fully override encryptVauMessage() to split the two counter uses explicitly. The override needs to use two distinct counter values per A_24632: the server's own counter for the IV's counter portion, and the client's stored value for the response header's Request-Counter field. Until that change is in place, treat the inner-VAU server-to-client channel as offering integrity and confidentiality only on the order of 2^32 messages per session before the GCM guarantees degrade.

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. The Java library has been pulled in unchanged by at least one production-side consumer (med-united/epa4all); audit your own dependency tree before assuming you're not affected.

• Add a server-side counter in your build.

  Override the server's encryptVauMessage() to maintain an independent 64-bit counter, increment it before each encryption, and use that counter (not the client's value) for the IV's counter portion. Keep the response header's Request-Counter field echoing the client's value, per A_24632.

• Treat session length as a security parameter.

  Until a server-side counter is in place, rotate VAU sessions well below the 2^32 message boundary. The IV-collision probability passes 1 % around 10,000 same-counter responses; that is your operational margin.

• Log Request-Counter values seen on the server.

  Even if you do not change the protocol behaviour, a counter that repeats or steps backwards across many responses in a single session is detectable. Capture and review it; the same metric covers misconfigured clients and active abuse.

Severity Reasoning

References

• gemSpec_Krypt V2.40.0 (A_24631, A_24632, A_24623)
• NIST SP 800-38D (AES-GCM)
• Joux (2006) — Authentication Failures in NIST version of GCM
• gematik lib-vau (Java) Repository
• gematik lib-vau-csharp Repository
• Related: Missing VAU Server Authentication (MS-LIB-VAU-eaea8d)
• Related: ePA-VAU Client Security overview

How We Can Help

• MDR Penetration Testing