Zusammenfassung

  • Ein CMS-AuthEnvelopedData kann AES-GCM korrekt benennen, gültige Parameter tragen und die Tag-Prüfung bestehen, ohne die frühere Nichtverwendung derselben Schlüssel/Nonce-Kombination zu beweisen.
  • RFC 5084 verlangt automatisiertes Schlüsselmanagement und beschreibt einen frischen CEK pro Inhalt als sichere Konstruktion; Algorithmusunterstützung ist kein Nachweis für diesen Lebenszyklus.

Der Prüfer hat den Umschlag, den Algorithmusbezeichner, zwölf Nonce-Oktette und ein gültiges Tag. Für einen belastbaren Befund fehlt trotzdem eine Akte: Welche anderen Umschläge wurden jemals mit demselben Inhaltsschlüssel erzeugt?

RFC 5084 bindet AES-CCM und AES-GCM an den CMS-Inhaltstyp AuthEnvelopedData. Sie ordnet den Algorithmusbezeichner ein, vergibt OIDs für jede AES-Schlüssellänge, schreibt Parameter vor und macht authentifizierte CMS-Attribute zu Additional Authenticated Data.

Die Nonce-Regel gilt im Schlüsselumfang. Für einen gegebenen authentifizierten Inhaltsschlüssel darf kein Nonce-Wert doppelt vorkommen. Werden Schlüssel und Nonce für verschiedene Nachrichten wiederverwendet, gehen die Sicherheitseigenschaften verloren. Das aktuelle Objekt kennt jedoch weder eine entfernte Instanz noch ein altes Archiv oder einen wiederhergestellten Zähler.

Darum belegt eine Länge von zwölf Oktetten nur die Form. Sie ist für GCM empfohlen und effizient, schließt aber die Wiederholung durch einen Klon nicht aus. Auch ein zufällig wirkender Wert beweist nicht, dass der Zustand des Zufallszahlengenerators nicht kopiert wurde.

RFC 5084 fordert deshalb ein automatisiertes Schlüsselmanagementsystem. Sie behandelt Schlüsseltransport, Schlüsselvereinbarung, symmetrische Schlüsselverschlüsselungsschlüssel und aus Kennwörtern abgeleitete Schlüssel. Die vier Wege erfüllen die Forderung, wenn für jeden Inhalt ein frischer Content-Authenticated-Encryption Key, CEK, erzeugt wird.

Ein frischer CEK pro Inhalt verkleinert die gemeinsame Geschichte. Gleiche Nonce-Bytes unter tatsächlich verschiedenen CEKs sind nicht dasselbe verbotene Paar. Bei einem langlebigen CEK muss dagegen eine atomare, dauerhafte Nonce-Vergabe alle Prozesse, Regionen, Sicherungen und Wiederanläufe dieses Schlüssels umfassen.

Die Objektparameter behalten ihre eigene Prüfkraft. GCMParameters enthält Nonce und eine ICV-Länge von zwölf bis sechzehn Oktetten; zwölf ist Standard und Empfehlung. Die Angabe muss zum mac-Feld passen. CCM erlaubt sieben bis dreizehn Nonce-Oktette und gerade ICV-Längen von vier bis sechzehn, mit zwölf als Empfehlung. Die Nonce-Länge steht dort zudem in einem Verhältnis zur darstellbaren Inhaltslänge.

Fehlende Parameter, unmögliche Werte und Längenabweichungen sind zurückzuweisen. Ein Bestehen belegt die Kodierung dieses Objekts, nicht die Güte der CEK-Erzeugung, die lokale Risikopolitik oder den Zustand eines zweiten Senders.

RFC 5083 definiert den Container. In RFC 5084 werden authentifizierte Attribute als AAD geschützt, aber nicht verborgen. MAC beziehungsweise Tag umfasst sie und den verschlüsselten Inhalt. Nicht authentifizierte Attribute erhalten durch räumliche Nähe keine Autorität.

Eine Anwendung darf daher aus einem gültigen Tag keine umfassende Freigabe ableiten. Das Tag belegt die Integrität der geschützten Eingaben unter dem verwendeten Schlüssel. Es belegt weder eine Person, noch die geschäftliche Berechtigung des Empfängers oder den Erfolg der nachfolgenden Verarbeitung.

Die allgemeine AEAD-Schnittstelle aus RFC 5116 verarbeitet Schlüssel, Nonce, Klartext und zugeordnete Daten. Der Algorithmus durchsucht keine ausgelagerte Historie. Auch NIST SP 800-38D behandelt IV-Eindeutigkeit als kritische GCM-Betriebsbedingung.

Ein Audit braucht deshalb eine nicht geheime Schlüssel-Epochenkennung. Mit ihr sollten Vergabenamespace und atomarer Nonce-Vorgang, exakte AAD-Kodierung, Chiffrat-Hash, Tag-Länge, Prüfergebnis und Softwarestand verbunden werden. Schlüsselbytes und Klartext gehören nicht in gewöhnliche Protokolle.

Bei einer Wiederherstellung kann der gespeicherte Zähler hinter dem bereits verwendeten Stand liegen. Der erste neue Umschlag ist syntaktisch korrekt und einzeln prüfbar, wiederholt aber möglicherweise ein altes Paar. Umgekehrt können zwei frische CEKs dieselben Nonce-Bytes sicher verwenden. Ohne reale Schlüssel-Epoche meldet die Überwachung entweder zu wenig oder zu viel.

Die Nachweiskette trennt CMS-Bytes; OID und Parameter; CEK-Epoche oder Frischschlüsselnachweis; Nonce-Vergabe; genaue authentifizierte Attribute; Chiffrat und Tag; Empfänger und Schlüsselverwaltungszweig; Parsing, Schlüsselöffnung und Tag-Prüfung; historische Suche; Klartextfreigabe; Anwendungsautorisierung und Ergebnis.

Diese Liste ist eine Betriebsempfehlung und keine zusätzliche RFC-Syntax. Nach Heng Lus Trennung der Realitätsebenen sind Algorithmusname, Objekt, Tag, historische Eindeutigkeit und Geschäftsentscheidung benachbarte, aber verschiedene Nachweise.

Quellen