4. Inhaltsverschlüsselungsalgorithmen

4. Inhaltsverschlüsselungsalgorithmen

Abschnitt 8.3 von [RFC9052] enthält eine allgemeine Beschreibung von Inhaltsverschlüsselungsalgorithmen. Dieses Dokument definiert den Bezeichner und die Verwendung für drei Inhaltsverschlüsselungsalgorithmen.

4.1. AES-GCM

Der Galois/Counter Mode (GCM) ist ein allgemeiner AEAD-Blockchiffre-Modus, der in [AES-GCM] definiert ist. Der GCM-Modus wird mit dem AES-Blockverschlüsselungsalgorithmus kombiniert, um eine AEAD-Chiffre zu definieren.

Der GCM-Modus wird durch die Größe des Authentifizierungs-Tags und die Größe der Nonce parametrisiert. Dieses Dokument fixiert die Größe der Nonce auf 96 Bit. Die Größe des Authentifizierungs-Tags ist auf einen kleinen Satz von Werten beschränkt. Für dieses Dokument ist die Größe des Authentifizierungs-Tags jedoch auf 128 Bit festgelegt.

Der Satz der in diesem Dokument definierten Algorithmen befindet sich in Tabelle 5.

  +=========+=======+==========================================+
  | Name    | Wert  | Beschreibung                             |
  +=========+=======+==========================================+
  | A128GCM |   1   | AES-GCM-Modus mit 128-Bit-Schlüssel,     |
  |         |       | 128-Bit-Tag                              |
  +---------+-------+------------------------------------------+
  | A192GCM |   2   | AES-GCM-Modus mit 192-Bit-Schlüssel,     |
  |         |       | 128-Bit-Tag                              |
  +---------+-------+------------------------------------------+
  | A256GCM |   3   | AES-GCM-Modus mit 256-Bit-Schlüssel,     |
  |         |       | 128-Bit-Tag                              |
  +---------+-------+------------------------------------------+

              Tabelle 5: Algorithmuswerte für AES-GCM

Schlüssel können entweder aus einer Schlüsselstruktur oder einer Empfängerstruktur erhalten werden. Implementierungen, die verschlüsseln oder entschlüsseln, MÜSSEN validieren, dass der Schlüsseltyp, die Schlüssellänge und der Algorithmus für die beteiligten Entitäten korrekt und angemessen sind.

Bei der Verwendung eines COSE-Schlüssels für diesen Algorithmus werden folgende Überprüfungen durchgeführt:

• Das Feld "kty" MUSS vorhanden sein und es MUSS "Symmetric" sein.

• Wenn das Feld "alg" vorhanden ist, MUSS es mit dem verwendeten AES-GCM-Algorithmus übereinstimmen.

• Wenn das Feld "key_ops" vorhanden ist, MUSS es beim Verschlüsseln "encrypt" oder "wrap key" enthalten.

• Wenn das Feld "key_ops" vorhanden ist, MUSS es beim Entschlüsseln "decrypt" oder "unwrap key" enthalten.

4.1.1. Sicherheitsüberlegungen für AES-GCM

Bei der Verwendung von AES-GCM MÜSSEN folgende Einschränkungen durchgesetzt werden:

• Das Schlüssel- und Nonce-Paar MUSS für jede verschlüsselte Nachricht eindeutig sein.

• Die Gesamtzahl der für einen einzelnen Schlüssel verschlüsselten Nachrichten DARF NICHT 2^32 überschreiten [SP800-38D]. Eine explizite Überprüfung ist nur in Umgebungen erforderlich, in denen erwartet wird, dass diese Grenze überschritten werden könnte.

• [RFC8446] enthält eine Analyse zur Verwendung von AES-CGM für seine Umgebung. Basierend auf dieser Empfehlung sollte man die Anzahl der verschlüsselten Nachrichten auf 2^24.5 beschränken.

• Eine neuere Analyse in [ROBUST] zeigt, dass die Anzahl der fehlgeschlagenen Entschlüsselungen berücksichtigt werden muss, um zu bestimmen, wann ein Schlüsselwechsel durchgeführt werden soll. Gemäß der Empfehlung in DTLS (Abschnitt 4.5.3 von [RFC9147]) sollte die Anzahl der fehlgeschlagenen Nachrichtenentschlüsselungen auf 2^36 begrenzt werden.

Es wurde erwogen, kleinere Tag-Werte zu unterstützen; die eingeschränkte Community würde Tag-Größen im 64-Bit-Bereich wünschen. Eine solche Verwendung ändert sowohl die maximale Nachrichtengröße (im Allgemeinen kein Problem) als auch die Anzahl der Male, die ein Schlüssel verwendet werden kann, drastisch. Da Counter with CBC-MAC (CCM) der übliche Modus für eingeschränkte Umgebungen ist, werden eingeschränkte Modi nicht unterstützt.

4.2. AES-CCM

CCM ist ein allgemeiner Authentifizierungsverschlüsselungs-Blockchiffre-Modus, der in [RFC3610] definiert ist. Der CCM-Modus wird mit dem AES-Blockverschlüsselungsalgorithmus kombiniert, um eine AEAD-Chiffre zu definieren, die häufig in eingeschränkten Geräten verwendet wird.

Der CCM-Modus hat zwei Parameteroptionen. Die erste Wahl ist M, die Größe des Authentifizierungsfeldes. Die Wahl des Wertes für M beinhaltet einen Kompromiss zwischen dem Nachrichtenwachstum (durch das Tag) und der Wahrscheinlichkeit, dass ein Angreifer eine Nachricht unbemerkt ändern kann. Die zweite Wahl ist L, die Größe des Längenfeldes. Dieser Wert erfordert einen Kompromiss zwischen der maximalen Nachrichtengröße und der Größe der Nonce.

Es ist bedauerlich, dass die Spezifikation für CCM L und M als Anzahl von Bytes anstatt als Anzahl von Bits spezifiziert hat. Dies führt zu möglichen Missverständnissen, bei denen AES-CCM-8 häufig verwendet wird, um auf eine Version des CCM-Modus zu verweisen, bei der die Größe der Authentifizierung 64 Bit und nicht 8 Bit beträgt. In den meisten kryptografischen Algorithmus-Spezifikationen wurden diese Werte traditionell als Bitanzahl und nicht als Byteanzahl angegeben. Dieses Dokument folgt der Konvention, Bitanzahlen zu verwenden, damit die verschiedenen in diesem Dokument vorgestellten Algorithmen leichter verglichen werden können.

Wir definieren in diesem Dokument eine Matrix von Algorithmen über die Werte von L und M. Eingeschränkte Geräte arbeiten normalerweise in Situationen, in denen sie kurze Nachrichten verwenden und empfängerspezifische kryptografische Operationen vermeiden möchten. Dies begünstigt kleinere Werte von L und M. Weniger eingeschränkte Geräte werden größere Nachrichten verwenden wollen und sind eher bereit, für jede Operation neue Schlüssel zu generieren. Dies begünstigt größere Werte von L und M.

Die folgenden Werte werden für L verwendet:

16 Bit (2): Dies begrenzt Nachrichten auf eine Länge von 2^16 Bytes (64 KiB). Dies ist für Nachrichten in der eingeschränkten Welt ausreichend lang. Die Nonce-Länge beträgt 13 Bytes, was 2^104 mögliche Werte der Nonce ohne Wiederholung ermöglicht.

64 Bit (8): Dies begrenzt Nachrichten auf eine Länge von 2^64 Bytes. Die Nonce-Länge beträgt 7 Bytes, was 2^56 mögliche Werte der Nonce ohne Wiederholung ermöglicht.

Die folgenden Werte werden für M verwendet:

64 Bit (8): Dies erzeugt ein 64-Bit-Authentifizierungs-Tag. Dies impliziert, dass es eine Chance von 1 zu 2^64 gibt, dass eine geänderte Nachricht authentifiziert wird.

128 Bit (16): Dies erzeugt ein 128-Bit-Authentifizierungs-Tag. Dies impliziert, dass es eine Chance von 1 zu 2^128 gibt, dass eine geänderte Nachricht authentifiziert wird.

+====================+=======+====+=====+========+===============+
| Name               | Wert  | L  | M   | Schlüs-| Beschreibung  |
|                    |       |    |     | sellä- |               |
|                    |       |    |     | nge    |               |
+====================+=======+====+=====+========+===============+
| AES-CCM-16-64-128  |   10  | 16 | 64  |  128   | AES-CCM-Modus |
|                    |       |    |     |        | 128-Bit-Schl.,|
|                    |       |    |     |        | 64-Bit-Tag,   |
|                    |       |    |     |        | 13-Byte-Nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-64-256  |   11  | 16 | 64  |  256   | AES-CCM-Modus |
|                    |       |    |     |        | 256-Bit-Schl.,|
|                    |       |    |     |        | 64-Bit-Tag,   |
|                    |       |    |     |        | 13-Byte-Nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-128  |   12  | 64 | 64  |  128   | AES-CCM-Modus |
|                    |       |    |     |        | 128-Bit-Schl.,|
|                    |       |    |     |        | 64-Bit-Tag,   |
|                    |       |    |     |        | 7-Byte-Nonce  |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-256  |   13  | 64 | 64  |  256   | AES-CCM-Modus |
|                    |       |    |     |        | 256-Bit-Schl.,|
|                    |       |    |     |        | 64-Bit-Tag,   |
|                    |       |    |     |        | 7-Byte-Nonce  |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-128 |   30  | 16 | 128 |  128   | AES-CCM-Modus |
|                    |       |    |     |        | 128-Bit-Schl.,|
|                    |       |    |     |        | 128-Bit-Tag,  |
|                    |       |    |     |        | 13-Byte-Nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-256 |   31  | 16 | 128 |  256   | AES-CCM-Modus |
|                    |       |    |     |        | 256-Bit-Schl.,|
|                    |       |    |     |        | 128-Bit-Tag,  |
|                    |       |    |     |        | 13-Byte-Nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-128 |   32  | 64 | 128 |  128   | AES-CCM-Modus |
|                    |       |    |     |        | 128-Bit-Schl.,|
|                    |       |    |     |        | 128-Bit-Tag,  |
|                    |       |    |     |        | 7-Byte-Nonce  |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-256 |   33  | 64 | 128 |  256   | AES-CCM-Modus |
|                    |       |    |     |        | 256-Bit-Schl.,|
|                    |       |    |     |        | 128-Bit-Tag,  |
|                    |       |    |     |        | 7-Byte-Nonce  |
+--------------------+-------+----+-----+--------+---------------+

              Tabelle 6: Algorithmuswerte für AES-CCM

Schlüssel können entweder aus einer Schlüsselstruktur oder einer Empfängerstruktur erhalten werden. Implementierungen, die verschlüsseln oder entschlüsseln, MÜSSEN validieren, dass der Schlüsseltyp, die Schlüssellänge und der Algorithmus für die beteiligten Entitäten korrekt und angemessen sind.

Bei der Verwendung eines COSE-Schlüssels für diesen Algorithmus werden folgende Überprüfungen durchgeführt:

• Das Feld "kty" MUSS vorhanden sein und es MUSS "Symmetric" sein.

• Wenn das Feld "alg" vorhanden ist, MUSS es mit dem verwendeten AES-CCM-Algorithmus übereinstimmen.

• Wenn das Feld "key_ops" vorhanden ist, MUSS es beim Verschlüsseln "encrypt" oder "wrap key" enthalten.

• Wenn das Feld "key_ops" vorhanden ist, MUSS es beim Entschlüsseln "decrypt" oder "unwrap key" enthalten.

4.2.1. Sicherheitsüberlegungen für AES-CCM

Bei der Verwendung von AES-CCM MÜSSEN folgende Einschränkungen durchgesetzt werden:

• Das Schlüssel- und Nonce-Paar MUSS für jede verschlüsselte Nachricht eindeutig sein. Beachten Sie, dass der Wert von L die Anzahl der eindeutigen Nonces beeinflusst.

• Die Gesamtzahl der Verwendungen der AES-Blockchiffre DARF 2^61 Operationen NICHT überschreiten. Diese Grenze ist die Summe der Male, die die Blockchiffre bei der Berechnung des MAC-Wertes und der Durchführung von Stream-Verschlüsselungsoperationen verwendet wird. Eine explizite Überprüfung ist nur in Umgebungen erforderlich, in denen erwartet wird, dass diese Grenze überschritten werden könnte.

• [RFC9147] enthält eine Analyse zur Verwendung von AES-CCM für seine Umgebung. Basierend auf dieser Empfehlung sollte man die Anzahl der verschlüsselten Nachrichten auf 2^23 beschränken.

• Zusätzlich zur Anzahl der erfolgreich entschlüsselten Nachrichten muss auch die Anzahl der fehlgeschlagenen Entschlüsselungen verfolgt werden. Gemäß der Empfehlung in DTLS (Abschnitt 4.5.3 von [RFC9147]) sollte die Anzahl der fehlgeschlagenen Nachrichtenentschlüsselungen auf 2^23.5 begrenzt werden. Wenn man das 64-Bit-Tag verwendet, sind die Grenzen deutlich kleiner, wenn man die gleichen Integritätsgrenzen beibehalten möchte. Ein Protokoll, das dies empfiehlt, muss analysieren, welches Integritätsniveau für die kleinere Tag-Größe akzeptabel ist. Es kann sein, dass man, um das gewünschte Integritätsniveau beizubehalten, so oft wie alle 2^7 Nachrichten einen neuen Schlüssel generieren muss.

[RFC3610] nennt zusätzlich eine weitere bemerkenswerte Überlegung. Es ist möglich, einen Vorausberechnungsangriff gegen den Algorithmus in Fällen durchzuführen, in denen Teile des Klartextes stark vorhersehbar sind. Dies reduziert die Sicherheit der Schlüsselgröße um die Hälfte. Möglichkeiten, mit diesem Angriff umzugehen, umfassen das Hinzufügen eines zufälligen Teils zum Nonce-Wert und/oder das Erhöhen der verwendeten Schlüsselgröße. Die Verwendung eines Teils der Nonce für einen zufälligen Wert verringert die Anzahl der Nachrichten, für die ein einzelner Schlüssel verwendet werden kann. Das Erhöhen der Schlüsselgröße kann im eingeschränkten Gerät mehr Ressourcen erfordern. Siehe Abschnitte 5 und 10 von [RFC3610] für weitere Informationen.

4.3. ChaCha20 und Poly1305

ChaCha20 und Poly1305 kombiniert ist ein AEAD-Modus, der in [RFC8439] definiert ist. Dies ist ein Algorithmus, der unter Verwendung einer Chiffre definiert ist, die nicht AES ist und daher nicht unter zukünftigen Schwächen leiden würde, die in AES gefunden werden. Diese kryptografischen Funktionen sind so konzipiert, dass sie in reinen Software-Implementierungen schnell sind.

Die in [RFC8439] definierte ChaCha20/Poly1305 AEAD-Konstruktion hat keine Parametrisierung. Sie nimmt als Eingaben einen 256-Bit-Schlüssel und eine 96-Bit-Nonce sowie den Klartext und zusätzliche Daten entgegen und erzeugt den Chiffretext als Ausgabe. Wir definieren einen Algorithmusbezeichner für diesen Algorithmus in Tabelle 7.

     +===================+=======+==========================+
     | Name              | Wert  | Beschreibung             |
     +===================+=======+==========================+
     | ChaCha20/Poly1305 |   24  | ChaCha20/Poly1305 mit    |
     |                   |       | 256-Bit-Schlüssel,       |
     |                   |       | 128-Bit-Tag              |
     +-------------------+-------+--------------------------+

          Tabelle 7: Algorithmuswert für ChaCha20/Poly1305

Schlüssel können entweder aus einer Schlüsselstruktur oder einer Empfängerstruktur erhalten werden. Implementierungen, die verschlüsseln oder entschlüsseln, MÜSSEN validieren, dass der Schlüsseltyp, die Schlüssellänge und der Algorithmus für die beteiligten Entitäten korrekt und angemessen sind.

Bei der Verwendung eines COSE-Schlüssels für diesen Algorithmus werden folgende Überprüfungen durchgeführt:

• Das Feld "kty" MUSS vorhanden sein und es MUSS "Symmetric" sein.

• Wenn das Feld "alg" vorhanden ist, MUSS es mit dem verwendeten ChaCha20/Poly1305-Algorithmus übereinstimmen.

• Wenn das Feld "key_ops" vorhanden ist, MUSS es beim Verschlüsseln "encrypt" oder "wrap key" enthalten.

• Wenn das Feld "key_ops" vorhanden ist, MUSS es beim Entschlüsseln "decrypt" oder "unwrap key" enthalten.

4.3.1. Sicherheitsüberlegungen für ChaCha20/Poly1305

Die Schlüssel- und Nonce-Werte MÜSSEN für jeden Aufruf des Algorithmus ein eindeutiges Paar sein. Nonce-Zähler werden als akzeptabler Weg angesehen, um sicherzustellen, dass sie eindeutig sind.

Eine neuere Analyse in [ROBUST] zeigt, dass die Anzahl der fehlgeschlagenen Entschlüsselungen berücksichtigt werden muss, um zu bestimmen, wann ein Schlüsselwechsel durchgeführt werden soll. Gemäß der Empfehlung in DTLS (Abschnitt 4.5.3 von [RFC9147]) sollte die Anzahl der fehlgeschlagenen Nachrichtenentschlüsselungen auf 2^36 begrenzt werden.

[RFC8446] merkt an, dass die (64-Bit) Datensatzsequenznummer umschlagen würde, bevor die Sicherheitsgrenze für ChaCha20/Poly1305 erreicht ist. COSE-Implementierungen sollten nicht mehr als 2^64 Nachrichten senden, die mit einem einzigen ChaCha20/Poly1305-Schlüssel verschlüsselt sind.