AES-GCM-Nonce-Wiederverwendung durch eingefrorenen VAU-Request-Counter

Beschreibung

self.encryption_counter = 0
self.request_counter = 0

header.extend(self.request_counter.to_bytes(8, "big"))

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 %

11m43s | 55451 unique IVs | prob: 30.1%

COLLISION after 57248 encrypted responses.
Response A (#53331): IV = e0cc7a0e 00000000
Response B (#57247): IV = e0cc7a0e 00000000

Patient ID digits (bytes 188-196):
  Pos 0: XOR=0x06  8 candidate pairs
  Pos 1: XOR=0x07  8 candidate pairs
  Pos 2: XOR=0x0b  4 candidate pairs
  Pos 3: XOR=0x04  8 candidate pairs
  Pos 4: XOR=0x07  8 candidate pairs
  Pos 5: XOR=0x06  8 candidate pairs
  Pos 6: XOR=0x0d  4 candidate pairs
  Pos 7: XOR=0x02  8 candidate pairs
  Pos 8: XOR=0x0d  4 candidate pairs

9/9 digits differ between the two patients.
Search space: 1,000,000,000 -> 16,777,216
Reduced by factor 60x from a single collision.

Auswirkung

• Die innere VAU-Schicht schützt Medikationsdaten, Diagnoseberichte, Verordnungshistorien, KVNRs, Dokumenten-Reads und -Writes einer Betroffenen sowie die Autorisierungstransaktionen, die den Zugriff auf die Patientenakte steuern.
• Eine passiv mithörende Angreiferin, die nur verschlüsselte VAU-Antworten auf dem Netzwerkpfad beobachtet, kann auf eine Geburtstags-IV-Kollision warten (~77.000 Antworten für 50 % Wahrscheinlichkeit, während eines Testlaufs bei ~57.000 beobachtet) und KVNR-Ziffern sowie weiteren vorhersehbaren Klartext aus dem XOR der beiden kollidierenden Ciphertexte rekonstruieren. Die Vorbedingung ist passive Netzbeobachtung; keine aktive Intervention ist nötig.
• Eine Angreiferin, die zwei Ciphertexte unter demselben IV gewinnt, rekonstruiert mit dem Joux Forbidden Attack den GHASH-Authentifizierungsschlüssel H. Mit H fälscht die Angreiferin das GCM-Authentifizierungs-Tag für Ciphertexte unter jedem IV, für den eine Kollision beobachtet wurde, sodass Server-zu-Client-VAU-Nachrichten manipulierbar werden: durch das Einschleusen falscher Patientendaten oder gefälschter Autorisierungsantworten.
• Wenn auch fbeta: TLS-Zertifikatsprüfung universell deaktiviert unmitigiert ist, entfällt durch die TLS-Terminierung die Vorbedingung der passiven Beobachtung und das systemweite AC sinkt auf L.

Abhilfe

Aktualisieren Sie fbeta ePA3-Service-OpenSource auf 1.3.0 oder höher. Der Fix inkrementiert request_counter bei jeder ausgehenden Nachricht und validiert die Monotonie des Antwort-Counters, um Replays zu verhindern. Dieselbe Wurzelursache existiert upstream im gematik-lib-vau-Server (der den Client-Counter ohne Monotonie-Prüfung speichert und als IV-Counter-Teil nutzt); siehe den gematik: AES-GCM-Nonce-Wiederverwendung in der VAU-Server-Verschlüsselung. Ein downstream-seitiger Fix, der stets einen frischen Counter sendet, entfernt den passiven Auslöser der serverseitigen Bedingung, schließt aber nicht die serverseitige Lücke gegen einen aktiven MITM, der auf der Relay-Ebene einen fixen Counter setzt.

Checkliste für Betreiber

• Auf fbeta ePA3-Service-OpenSource 1.3.0 oder höher aktualisieren.

  Alle Versionen vor 1.3.0 sind betroffen. Der Fix liegt in Pull Request #10.

• Das Inkrement im eigenen Build verifizieren.

  Ergänzen Sie in Ihrem Deployment der Bibliothek einen kurzen Integrationstest, der zwei aufeinanderfolgende ausgehende VAU-Nachrichten erfasst und prüft, dass sich das 8-Byte-request_counter-Feld im Header zwischen ihnen ändert. Die ursprüngliche Lücke manifestierte sich als einzelne fehlende Zeile im Verschlüsselungspfad; ein Integrations-Assert ist die billigste Versicherung gegen das Wiederauftauchen in einem Fork.

• Monotonie des Antwort-Counters prüfen.

  Der Fix ergänzt zusätzlich eine Monotonie-Prüfung des Antwort-Counters. Falls Sie einen eigenen Client pflegen, ersetzen Sie jede Gleichheits-Prüfung auf dem Antwort-Counter durch response_counter > last_seen_response_counter, um Replays vergangener Server-Antworten zu verhindern.

• Sitzungslänge als Sicherheitsparameter behandeln, bis der Fix ausgerollt ist.

  Bis das Inkrement in Ihrer Flotte greift, rotieren Sie VAU-Sitzungen deutlich unterhalb der 2^16-Nachrichten-Grenze. Die IV-Kollisionswahrscheinlichkeit übersteigt bereits bei rund 10.000 Antworten mit gleichem Counter die 1-Prozent-Schwelle; das ist Ihre operative Marge.

Bewertung im Detail

Referenzen

• GHSA-vmfm-3f7g-r9qg (fbeta)
• fbeta-ePA3-Service-OpenSource-PR #10 (Fix)
• fbeta-ePA3-Service-OpenSource-Repository
• gemSpec_Krypt A_24628-01 (Client-Verschlüsselungscounter)
• NIST SP 800-38D (AES-GCM)
• Joux (2006), Authentication Failures in NIST version of GCM
• Verwandter Upstream: AES-GCM-Nonce-Wiederverwendung in gematik lib-vau
• Verwandt: Deaktivierte TLS-Zertifikatsprüfung
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests