AES-GCM-Nonce-Wiederverwendung in der VAU-Server-Verschlüsselung

Beschreibung

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

Nachrichten  P(IV-Kollision)
        100  < 0,01 %
      1.000    0,01 %
     10.000    1,16 %
     50.000   25,23 %
     77.163   50,00 %
    100.000   68,55 %

Auswirkung

• In ePA-Begriffen umfassen die Payloads, die die innere VAU-Schicht schützt, Medikationsdaten, Diagnoseberichte, Verordnungshistorien, Dokumenten-Reads und -Writes sowie die Autorisierungstransaktionen, die den Zugriff auf eine Patientenakte steuern. Die folgenden beiden Effekte betreffen genau diese Payloads.
• Ein legitimer VAU-Client (oder ein Angreifer im Netzwerk, der einen VAU-Handshake abgeschlossen hat) kann den Counter-Teil des Server-IV konstant halten, indem er einen Request-Counter-Wert wiederverwendet, und so lange Server-Antworten sammeln, bis zwei denselben 12-Byte-IV teilen.
• Sobald zwei Antworten denselben IV teilen, rekonstruiert der Joux Forbidden Attack den GHASH-Authentifizierungsschlüssel H. Mit H kann der Angreifer das GCM-Authentifizierungs-Tag für Ciphertexte unter jedem IV fälschen, für den eine Kollision beobachtet wurde, und so Server-zu-Client-VAU-Nachrichten in einer Sitzung mit fortlaufender Nonce-Wiederverwendung manipulieren.
• Das XOR der beiden kollidierenden Ciphertexte ergibt das XOR der beiden Klartexte und gibt damit Informationen über die durch die innere VAU-AES-GCM-Schicht geschützten ePA-Antwort-Payloads preis.
• Oberhalb der inneren VAU-Schicht existiert zwar weiterhin TLS zum ePA-Backend, doch die innere VAU-Schicht ist die Eigenschaft, mit der das ePA-Bedrohungsmodell Patientendaten gegen die Kompromittierung von TLS-Infrastruktur außerhalb der TEE-Grenze schützt. Das Brechen dieser Schicht entfernt diese Defense-in-Depth-Grenze.
• In Kombination mit der fehlenden Server-Authentifizierung (MS-LIB-VAU-eaea8d) ist die Position des Angreifers nicht hypothetisch. Ein MITM, der während des Handshakes seine eigenen Schlüssel eingeschleust hat, kann den Client-Request-Counter bei jeder weitergeleiteten Anfrage auf einen festen Wert fixieren — und reduziert damit die Kollisionssammlung von einem aktiven Angriff auf passive Beobachtung eines Kanals, den der Angreifer bereits kontrolliert.

Abhilfe

Konsumenten, die eine der Bibliotheken produktiv einsetzen, sollten einen unabhängigen serverEncryptionCounter zu VauServerStateMachine (oder dessen C#-Äquivalent) hinzufügen, ihn auf 0 initialisieren und encryptVauMessage() so überschreiben, dass dieser Counter vor der Verschlüsselung inkrementiert wird. Eine reine Überschreibung von getRequestCounter() reicht nicht aus — super.encryptVauMessage() verwendet den Rückgabewert sowohl für den IV als auch für den Header, sodass der Server encryptVauMessage() vollständig überschreiben muss, um die beiden Counter-Verwendungen explizit zu trennen. Die Überschreibung muss gemäß A_24632 zwei unterschiedliche Counter-Werte verwenden: den eigenen Counter des Servers für den Counter-Teil des IV und den gespeicherten Client-Wert für das Request-Counter-Feld im Antwort-Header. Bis diese Änderung umgesetzt ist, sollte der innere VAU-Server-zu-Client-Kanal so behandelt werden, als biete er Integrität und Vertraulichkeit nur in der Größenordnung von 2^32 Nachrichten pro Sitzung, bevor die GCM-Garantien nachlassen.

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. Die Java-Bibliothek wurde von mindestens einem produktiven Konsumenten unverändert übernommen (med-united/epa4all); prüfen Sie Ihren eigenen Abhängigkeitsbaum, bevor Sie davon ausgehen, nicht betroffen zu sein.

• Einen serverseitigen Counter in Ihrem Build hinzufügen.

  Überschreiben Sie encryptVauMessage() des Servers so, dass ein unabhängiger 64-Bit-Counter geführt, vor jeder Verschlüsselung inkrementiert und genau dieser Counter (nicht der Wert des Clients) für den Counter-Teil des IV verwendet wird. Lassen Sie das Request-Counter-Feld im Antwort-Header gemäß A_24632 weiterhin den Client-Wert zurückspiegeln.

• Sitzungslänge als Sicherheitsparameter behandeln.

  Bis ein serverseitiger Counter etabliert ist, rotieren Sie VAU-Sitzungen deutlich unterhalb der 2^32-Nachrichten-Grenze. Die IV-Kollisionswahrscheinlichkeit übersteigt bereits bei rund 10.000 Antworten mit gleichem Counter die 1-Prozent-Schwelle; das ist Ihre operative Marge.

• Auf dem Server gesehene Request-Counter-Werte protokollieren.

  Auch wenn Sie das Protokollverhalten nicht ändern, ist ein Counter, der sich innerhalb einer Sitzung über viele Antworten hinweg wiederholt oder rückwärts läuft, erkennbar. Erfassen und prüfen Sie ihn; dieselbe Metrik deckt fehlkonfigurierte Clients und aktiven Missbrauch ab.

Bewertung im Detail

Referenzen

• 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-Repository (Java)
• gematik-lib-vau-csharp-Repository
• Verwandt: Fehlende VAU-Server-Authentifizierung (MS-LIB-VAU-eaea8d)
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests