11. Sicherheitsüberlegungen

11. Sicherheitsüberlegungen

Es gibt eine Reihe von Sicherheitsüberlegungen, die von Implementierern dieser Spezifikation berücksichtigt werden müssen. Die Sicherheitsüberlegungen, die für einen einzelnen Algorithmus spezifisch sind, befinden sich neben der Beschreibung des Algorithmus. 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 legt den direkten Schlüssel gegenüber dem zweiten Empfänger offen; Abschnitt 8.5 von [RFC9052] verbietet die Kombination von "direct"-Empfängeralgorithmen mit anderen Modi.

• Mehrere der Algorithmen in diesem Dokument haben Einschränkungen hinsichtlich der Häufigkeit, mit der ein Schlüssel verwendet werden kann, ohne Informationen über den Schlüssel preiszugeben.

Die Verwendung von ECDH und Direct plus KDF (ohne Key Wrap) führt nicht direkt dazu, dass der private Schlüssel preisgegeben wird; die Einwegfunktion der KDF verhindert dies. Es gibt jedoch ein anderes Problem, das angegangen werden muss. Wenn es zwei Empfänger gibt, muss der CEK zwischen zwei Empfängern geteilt werden. Der zweite Empfänger verfügt daher über 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 entweder für Static-Static ECDH oder Direct 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, sollte wiederholt werden, dass die Verwendung eines einzigen Schlüssels für mehrere Algorithmen in einigen Fällen nachweislich Informationen über einen Schlüssel preisgibt, was 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üsselerstellern und Schlüsselkonsumenten wird dringend empfohlen, 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. Neben der Ü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. Handelt es sich bei den Daten oder der Aktion um etwas, das die mit dem Schlüssel verbundene Entität sehen oder anfordern darf? Eine Reihe von Faktoren ist mit dieser Vertrauensentscheidung verbunden. Einige hier hervorgehobene sind:

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

• Ist der kryptografische 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 Header-Parameter "crit" angegeben)?

In diesem Dokument werden zahlreiche Algorithmen vorgestellt, die Nonce-Werte verwenden. Für alle in diesem Dokument definierten Nonces gibt es eine Art von Einschränkung, dass die Nonce ein eindeutiger Wert für entweder einen Schlüssel oder einige andere Bedingungen ist. In all diesen Fällen gibt es keine bekannte Anforderung, dass die Nonce sowohl eindeutig als auch unvorhersehbar sein muss; unter diesen Umständen ist es vernünftig, einen Zähler für die Erstellung der Nonce zu verwenden. In Fällen, in denen man möchte, dass das Muster der Nonce sowohl unvorhersehbar als auch eindeutig ist, kann man einen für diesen Zweck erstellten Schlüssel verwenden und den Zähler verschlüsseln, um den Nonce-Wert zu erzeugen.

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 (z. B. "JA" und "NEIN") basierend auf der Länge für alle in diesem Dokument definierten Inhaltsverschlüsselungsalgorithmen unterscheiden. Dies bedeutet, dass es den Anwendungen überlassen bleibt, zu dokumentieren, wie das Content Padding erfolgen soll, um eine solche Analyse zu verhindern oder zu entmutigen. (Zum Beispiel könnten die Textzeichenfolgen als "JA" und "NEIN " definiert werden.)

Die in [RFC9147] durchgeführte Analyse basiert auf der Anzahl der gesendeten Datensätze. Dies sollte gut auf die Anzahl der Nachrichten abgebildet werden, die bei der Verwendung von COSE gesendet werden, sodass diese Analyse hier auch gelten sollte, unter der Annahme, dass die COSE-Nachrichten ungefähr die gleiche Größe wie DTLS-Datensätze haben. Es muss beachtet werden, dass die Grenzen auf der Anzahl der Nachrichten basieren, aber QUIC und DTLS sind immer paarweise basierte Endpunkte. Im Gegensatz dazu verwendet [OSCORE-GROUPCOMM] COSE in einem Gruppenkommunikationsszenario. Unter diesen Umständen sieht möglicherweise keine einzelne Entität alle verschlüsselten Nachrichten, und daher kann keine einzelne Entität die Rekey-Operation auslösen.