3. Header-Parameter

Header-Parameter

Die Struktur von COSE wurde so konzipiert, dass sie zwei Informationsbereiche (Buckets) enthält, die nicht als Teil der Nutzlast selbst betrachtet werden, sondern dazu dienen, Informationen über Inhalt, Algorithmen, Schlüssel oder Auswertungshinweise für die Verarbeitung der Schicht zu speichern. Diese beiden Bereiche stehen in allen Strukturen zur Verfügung, mit Ausnahme von Schlüsseln. Obwohl diese Bereiche vorhanden sind, sind sie möglicherweise nicht immer in allen Fällen verwendbar. Beispielsweise ist der geschützte Bereich zwar als Teil der Empfängerstruktur definiert, einige der für Empfängerstrukturen verwendeten Algorithmen sehen jedoch keine authentifizierten Daten vor. In diesem Fall bleibt der geschützte Bereich leer.

Beide Bereiche sind als CBOR-Maps implementiert. Der Map-Schlüssel ist ein „Label“ (Abschnitt 1.5). Der Wertteil hängt von der Definition für das Label ab. Beide Maps verwenden denselben Satz von Label/Wert-Paaren. Die Ganzzahl- und Textzeichenfolgenwerte für Labels wurden in mehrere Abschnitte unterteilt, darunter ein Standardbereich, ein Bereich für die private Verwendung und ein Bereich, der vom ausgewählten Algorithmus abhängt. Die definierten Labels finden Sie im IANA-Register „COSE Header Parameters“ (Abschnitt 11.1).

Die beiden Bereiche sind:

protected (geschützt): Enthält Parameter zur aktuellen Schicht, die kryptografisch geschützt sind. Dieser Bereich MUSS leer sein, wenn er nicht in eine kryptografische Berechnung einbezogen werden soll. Dieser Bereich wird in der Nachricht als binäres Objekt codiert. Dieser Wert wird durch CBOR-Codierung der geschützten Map und deren Verpackung in ein bstr-Objekt erhalten. Sender SOLLTEN eine Map der Länge Null als Byte-String der Länge Null codieren und nicht als Map der Länge Null (codiert als h'a0'). Die Codierung als Byte-String der Länge Null wird bevorzugt, da sie sowohl kürzer ist als auch die Version ist, die in den Serialisierungsstrukturen für kryptografische Berechnungen verwendet wird. Empfänger MÜSSEN sowohl einen Byte-String der Länge Null als auch eine in einem Byte-String codierte Map der Länge Null akzeptieren.

  Das Verpacken der Codierung mit einem Byte-String ermöglicht es, die geschützte Map mit einer größeren Wahrscheinlichkeit zu transportieren, dass sie während des Transports nicht versehentlich geändert wird. (Schlecht erzogene Zwischenhändler könnten decodieren und neu codieren, aber dies führt zu einem Fehlschlag der Überprüfung, es sei denn, der neu codierte Byte-String ist identisch mit dem decodierten Byte-String.) Dies vermeidet das Problem, dass alle Parteien in der Lage sein müssen, eine gemeinsame kanonische Codierung der Map für die Eingabe in kryptografische Operationen durchzuführen.

unprotected (ungeschützt): Enthält Parameter zur aktuellen Schicht, die nicht kryptografisch geschützt sind.

Nur Header-Parameter, die sich mit der aktuellen Schicht befassen, sind auf dieser Schicht zu platzieren. Als Beispiel dafür beschreibt der Header-Parameter „content type“ den Inhalt der Nachricht, die in der Nachricht transportiert wird. Daher wird dieser Header-Parameter nur in der Inhaltsschicht platziert und nicht in den Empfänger- oder Signaturschichten. Im Prinzip sollte man in der Lage sein, jede gegebene Schicht ohne Bezugnahme auf eine andere Schicht zu verarbeiten. Mit Ausnahme der COSE_Sign-Struktur sind die einzigen Daten, die Schichten überschreiten müssen, der kryptografische Schlüssel.

Die Bereiche sind in allen in diesem Dokument definierten Sicherheitsobjekten vorhanden. Die Felder sind in der Reihenfolge der „geschützte“ Bereich (als CBOR-Typ „bstr“) und dann der „ungeschützte“ Bereich (als CBOR-Typ „map“). Das Vorhandensein beider Bereiche ist erforderlich. Die Header-Parameter, die in die Bereiche gelangen, stammen aus dem IANA-Register „COSE Header Parameters“ (Abschnitt 11.1). Einige Header-Parameter werden im nächsten Abschnitt definiert.

Labels in jeder der Maps MÜSSEN eindeutig sein. Wenn beim Verarbeiten von Nachrichten ein Label mehrmals erscheint, MUSS die Nachricht als fehlerhaft abgelehnt werden. Anwendungen SOLLTEN überprüfen, dass dasselbe Label nicht sowohl in den geschützten als auch in den ungeschützten Header-Parametern vorkommt. Wenn die Nachricht nicht als fehlerhaft abgelehnt wird, MÜSSEN Attribute aus dem geschützten Bereich erhalten werden, und nur wenn ein Attribut nicht im geschützten Bereich gefunden wird, kann dieses Attribut aus dem ungeschützten Bereich erhalten werden.

Das folgende CDDL-Fragment stellt die beiden Header-Parameter-Bereiche dar. In CDDL wird eine Gruppe „Headers“ definiert, die die beiden Bereiche darstellt, in denen Attribute platziert werden. Diese Gruppe wird verwendet, um diese beiden Felder an allen Orten konsistent bereitzustellen. Es wird auch ein Typ definiert, der die Map der gemeinsamen Header-Parameter darstellt.

   Headers = (
       protected : empty_or_serialized_map,
       unprotected : header_map
   )

   header_map = {
       Generic_Headers,
       * label => values
   }

   empty_or_serialized_map = bstr .cbor header_map / bstr .size 0

3.1. Gemeinsame COSE-Header-Parameter

Dieser Abschnitt definiert einen Satz gemeinsamer Header-Parameter. Eine Zusammenfassung dieser Header-Parameter finden Sie in Tabelle 3. Diese Tabelle sollte konsultiert werden, um den Wert des Labels und den Typ des Werts zu bestimmen.

Der in diesem Abschnitt definierte Satz von Header-Parametern ist wie folgt:

alg: Dieser Header-Parameter wird verwendet, um den für die Sicherheitsverarbeitung verwendeten Algorithmus anzugeben. Dieser Header-Parameter MUSS authentifiziert werden, wo die Möglichkeit dazu besteht. Diese Unterstützung wird durch AEAD-Algorithmen oder -Konstruktionen (z. B. COSE_Sign und COSE_Mac0) bereitgestellt. Diese Authentifizierung kann entweder durch Platzierung des Header-Parameters im Bereich der geschützten Header-Parameter oder als Teil der extern bereitgestellten Daten (Abschnitt 4.3) erfolgen. Der Wert wird aus dem Register „COSE Algorithms“ entnommen (siehe [COSE.Algorithms]).

crit: Dieser Header-Parameter wird verwendet, um anzugeben, welche geschützten Header-Parameter eine Anwendung, die eine Nachricht verarbeitet, verstehen muss. In diesem Dokument definierte Header-Parameter müssen nicht enthalten sein, da sie von allen Implementierungen verstanden werden sollten. Darüber hinaus muss der durch [RFC8152] definierte Header-Parameter „counter signature“ (Label 7) von neuen Implementierungen verstanden werden, um kompatibel mit Absendern zu bleiben, die sich an dieses Dokument halten und davon ausgehen, dass alle Implementierungen es verstehen werden. Wenn vorhanden, MUSS der Header-Parameter „crit“ im Bereich der geschützten Header-Parameter platziert werden. Das Array MUSS mindestens einen Wert enthalten.

  Nicht alle Header-Parameter-Labels müssen in den Header-Parameter „crit“ aufgenommen werden. Die Regeln für die Entscheidung, welche Header-Parameter im Array platziert werden, sind:

  *  Ganzzahlige Labels im Bereich von 0 bis 7 SOLLTEN weggelassen werden.

  *  Ganzzahlige Labels im Bereich -1 bis -128 können weggelassen werden. Algorithmen können Labels in diesem Bereich zuweisen, wenn die Fähigkeit zur Verarbeitung des Inhalts des Labels als Kern für die Implementierung des Algorithmus angesehen wird. Algorithmen können Labels außerhalb dieses Bereichs zuweisen und sie in den Header-Parameter „crit“ aufnehmen, wenn die Fähigkeit zur Verarbeitung des Inhalts des Labels nicht als Kernfunktionalität des Algorithmus angesehen wird, aber verstanden werden muss, um diese Instanz korrekt zu verarbeiten. Ganzzahlige Labels im Bereich -129 bis -65536 SOLLTEN enthalten sein, da dies weniger häufige Header-Parameter wären, die möglicherweise nicht allgemein unterstützt werden.

  *  Labels für Header-Parameter, die für eine Anwendung erforderlich sind, KÖNNEN weggelassen werden. Anwendungen sollten eine Erklärung haben, die besagt, ob das Label weggelassen werden kann oder nicht.

  Die durch „crit“ angegebenen Header-Parameter können entweder durch den Sicherheitsbibliothekscode oder durch eine Anwendung, die eine Sicherheitsbibliothek verwendet, verarbeitet werden; die einzige Anforderung ist, dass der Header-Parameter verarbeitet wird. Wenn die „crit“-Werteliste ein Label enthält, für das sich der Header-Parameter nicht im Bereich der geschützten Header-Parameter befindet, ist dies ein schwerwiegender Fehler bei der Verarbeitung der Nachricht.

content type: Dieser Header-Parameter wird verwendet, um den Inhaltstyp der Daten im Feld „payload“ oder „ciphertext“ anzugeben. Ganzzahlen stammen aus der IANA-Registertabelle „CoAP Content-Formats“ [COAP.Formats]. Textwerte folgen der Syntax von „<type-name>/<subtype-name>“, wobei <type-name> und <subtype-name> in Abschnitt 4.2 von [RFC6838] definiert sind. Führende und abschließende Leerzeichen sind nicht zulässig. Textuelle Inhaltstypwerte sowie Parameter und Unterparameter können mithilfe des IANA-Registers „Media Types“ lokalisiert werden. Anwendungen SOLLTEN diesen Header-Parameter bereitstellen, wenn die Inhaltsstruktur möglicherweise mehrdeutig ist.

kid: Dieser Header-Parameter identifiziert ein Datenelement, das als Eingabe verwendet werden kann, um den benötigten kryptografischen Schlüssel zu finden. Der Wert dieses Header-Parameters kann mit dem „kid“-Mitglied in einer COSE_Key-Struktur abgeglichen werden. Andere Methoden der Schlüsselverteilung können ein äquivalentes Feld definieren, das abgeglichen werden soll. Anwendungen DÜRFEN NICHT annehmen, dass „kid“-Werte eindeutig sind. Es kann mehr als einen Schlüssel mit demselben „kid“-Wert geben, sodass möglicherweise alle mit diesem „kid“ verknüpften Schlüssel überprüft werden müssen. Die interne Struktur von „kid“-Werten ist nicht definiert und Anwendungen können sich nicht darauf verlassen. Schlüsselbezeichnerwerte sind Hinweise darauf, welcher Schlüssel verwendet werden soll. Dies ist kein sicherheitskritisches Feld. Aus diesem Grund kann es im Bereich der ungeschützten Header-Parameter platziert werden.

IV: Dieser Header-Parameter enthält den Wert des Initialisierungsvektors (IV). Bei einigen symmetrischen Verschlüsselungsalgorithmen kann dies als Nonce bezeichnet werden. Der IV kann im ungeschützten Bereich platziert werden, da bei AE- und AEAD-Algorithmen eine Änderung des IV dazu führt, dass die Entschlüsselung fehlschlägt.

Partial IV: Dieser Header-Parameter enthält einen Teil des IV-Werts. Bei Verwendung der COSE_Encrypt0-Struktur kann ein Teil des IV Teil des mit dem Schlüssel verbundenen Kontexts sein (Context IV), während ein Teil bei jeder Nachricht geändert werden kann (Partial IV). Dieses Feld wird verwendet, um einen Wert zu transportieren, der dazu führt, dass der IV für jede Nachricht geändert wird. Der Partial IV kann im ungeschützten Bereich platziert werden, da eine Änderung des Werts dazu führt, dass die Entschlüsselung Klartext ergibt, der leicht als verstümmelt erkennbar ist. Die Header-Parameter „Initialization Vector“ und „Partial Initialization Vector“ DÜRFEN NICHT beide in derselben Sicherheitsschicht vorhanden sein.

  Der Nachrichten-IV wird durch die folgenden Schritte generiert:

  1.  Den Partial IV mit Nullen bis zur Länge des IV (durch den Algorithmus bestimmt) links auffüllen.

  2.  Den aufgefüllten Partial IV mit dem Context IV XOR-verknüpfen.

                 Tabelle 3: Gemeinsame Header-Parameter

Das CDDL-Fragment, das den in diesem Abschnitt definierten Satz von Header-Parametern darstellt, ist unten angegeben. Jeder der Header-Parameter ist als optional gekennzeichnet, da sie nicht in jeder Map enthalten sein müssen; Header-Parameter, die in bestimmten Maps erforderlich sind, werden oben besprochen.

Generic_Headers = ( ? 1 => int / tstr, ; algorithm identifier ? 2 => [+label], ; criticality ? 3 => tstr / int, ; content type ? 4 => bstr, ; key identifier ? ( 5 => bstr // ; IV 6 => bstr ) ; Partial IV )