12. Sicherheitsüberlegungen

12. Sicherheitsüberlegungen

Es gibt eine Reihe von Sicherheitsüberlegungen, die von Implementierern dieser Spezifikation berücksichtigt werden müssen. Während einige Überlegungen hier hervorgehoben wurden, finden sich zusätzliche Überlegungen möglicherweise in den in den Referenzen aufgeführten Dokumenten.

Implementierungen müssen das private Schlüsselmaterial für alle Personen schützen. Einige Fälle in diesem Dokument müssen im Hinblick auf dieses Problem hervorgehoben werden.

• Die Verwendung desselben Schlüssels für zwei verschiedene Algorithmen kann Informationen über den Schlüssel preisgeben. Es wird daher empfohlen, Schlüssel auf einen einzigen Algorithmus zu beschränken.

• Die Verwendung von "direct" als Empfängeralgorithmus in Kombination mit einem zweiten Empfängeralgorithmus setzt den direkten Schlüssel dem zweiten Empfänger aus; Abschnitt 8.5 verbietet die Kombination von "direct"-Empfängeralgorithmen mit anderen Modi.

• Mehrere der Algorithmen in [RFC9053] haben Grenzen für die Anzahl der Male, die ein Schlüssel verwendet werden kann, ohne Informationen über den Schlüssel preiszugeben.

Die Verwendung von Elliptic Curve Diffie-Hellman (ECDH) und direkt plus KDF (ohne Key Wrap) führt nicht direkt dazu, dass der private Schlüssel preisgegeben wird; die Einwegfunktion des KDF verhindert dies. Es gibt jedoch ein anderes Problem, das angegangen werden muss. Das Vorhandensein von zwei Empfängern erfordert, dass der CEK zwischen zwei Empfängern geteilt wird. Der zweite Empfänger hat daher einen CEK, der aus Material abgeleitet wurde, das für den schwachen Herkunftsnachweis verwendet werden kann. Der zweite Empfänger könnte eine Nachricht mit demselben CEK erstellen und an den ersten Empfänger senden; der erste Empfänger würde sowohl für Static-Static ECDH als auch für direkt plus KDF annehmen, dass der CEK für den Herkunftsnachweis verwendet werden könnte, obwohl er von der falschen Entität stammt. Wenn der Key-Wrap-Schritt hinzugefügt wird, wird kein Herkunftsnachweis impliziert und dies ist kein Problem.

Obwohl es bereits erwähnt wurde, muss wiederholt werden, dass die Verwendung eines einzigen Schlüssels für mehrere Algorithmen in einigen Fällen nachweislich Informationen über einen Schlüssel preisgibt und Angreifern die Möglichkeit bietet, Integritäts-Tags zu fälschen oder Informationen über verschlüsselte Inhalte zu erhalten. Das Binden eines Schlüssels an einen einzigen Algorithmus verhindert diese Probleme. Schlüsselersteller und Schlüsselkonsumenten werden dringend ermutigt, nicht nur neue Schlüssel für jeden anderen Algorithmus zu erstellen, sondern diese Algorithmusauswahl in jede Verteilung von Schlüsselmaterial aufzunehmen und die Übereinstimmung von Algorithmen in der Schlüsselstruktur mit Algorithmen in der Nachrichtenstruktur strikt durchzusetzen. Zusätzlich zur Überprüfung, ob die Algorithmen korrekt sind, muss auch die Schlüsselform überprüft werden. Verwenden Sie keinen "EC2"-Schlüssel, wo ein "OKP"-Schlüssel erwartet wird.

Bevor ein Schlüssel für die Übertragung verwendet wird oder bevor auf empfangene Informationen reagiert wird, muss eine Vertrauensentscheidung über einen Schlüssel getroffen werden. Ist die Daten oder die Aktion etwas, das die mit dem Schlüssel verbundene Entität sehen oder anfordern darf? Eine Reihe von Faktoren sind mit dieser Vertrauensentscheidung verbunden. Einige hier hervorgehobene sind:

• Welche Berechtigungen sind mit dem Schlüsseleigentümer verbunden?

• Ist der kryptographische Algorithmus im aktuellen Kontext akzeptabel?

• Wurden die mit dem Schlüssel verbundenen Einschränkungen wie Algorithmus oder Aktualität überprüft und sind sie korrekt?

• Ist die Anfrage angesichts des aktuellen Zustands der Anwendung angemessen?

• Wurden Sicherheitsüberlegungen, die Teil der Nachricht sind, durchgesetzt (wie von der Anwendung oder dem "crit"-Header-Parameter angegeben)?

Ein Bereich, der Aufmerksamkeit erregt hat, ist die Verkehrsanalyse verschlüsselter Nachrichten basierend auf der Länge der Nachricht. Diese Spezifikation bietet keine einheitliche Methode zum Bereitstellen von Padding als Teil der Nachrichtenstruktur. Ein Beobachter kann zwischen zwei verschiedenen Nachrichten (zum Beispiel "JA" und "NEIN") basierend auf der Länge für alle in [RFC9053] definierten Inhaltsverschlüsselungsalgorithmen unterscheiden. Dies bedeutet, dass es den Anwendungen überlassen bleibt, zu dokumentieren, wie das Inhaltspadding erfolgen soll, um eine solche Analyse zu verhindern oder zu entmutigen. (Zum Beispiel könnten die Textzeichenfolgen als "JA" und "NEIN " definiert werden.)