Zusammenfassung

  • RFC 3657 ordnete Camellia in CMS unterschiedliche Kennungen für Inhaltsverschlüsselung und Key Wrap zu. CBC-Inhaltsverschlüsselung verlangt einen vorhandenen 16-Oktett-IV; beim Algorithmusbezeichner für Key Wrap müssen Parameter fehlen.
  • Eine S/MIME-Fähigkeitsmeldung verwendet eine dritte Form: den Parameter NULL. Die Key-Wrap-OID bezeichnet die Länge des Schlüsselverschlüsselungsschlüssels (KEK), nicht zwingend die Länge des verpackten Inhaltsschlüssels (CEK).

Derselbe Name bezeichnet nicht denselben Vorgang

In einer CMS-Kapsel sagt „Camellia“ allein nicht aus, was der Absender getan hat. Der Empfänger muss unterscheiden, ob der Algorithmus den Inhalt verschlüsselt oder den Inhaltsschlüssel (CEK) verpackt hat, und den Algorithmusbezeichner gemäß dieser Funktion auswerten. RFC 3657 erschien im Januar 2004 als Standards-Track-Dokument und legte dafür zwei Familien von Camellia-Kennungen fest: eine für CBC-Inhaltsverschlüsselung, eine für Key Wrap. RFC 3657

Die Parameter machen den Unterschied sichtbar. Bei id-camellia128-cbc, id-camellia192-cbc und id-camellia256-cbc MUSS das Parameterfeld von AlgorithmIdentifier vorhanden sein und den 16 Oktett langen Initialisierungsvektor enthalten. Der IV gehört zur Beschreibung der Inhaltsverschlüsselung; aus dem Namen der Chiffre lässt er sich nicht ableiten. Für die Auffüllung des Klartexts verweist RFC 3657 auf die CMS-Regel. RFC 3657 RFC 5652

Beim Key Wrap gilt die umgekehrte Erwartung. Die drei Camellia-Wrap-OIDs enthalten zwar jeweils einen Größen-Unterzweig, aber ihre AlgorithmIdentifier-Parameter MÜSSEN fehlen. Das Wrap-Verfahren selbst definiert, wie es seinen internen Anfangswert verwendet; das Feld überträgt daher keinen IV. Die OID-Größe bezeichnet den Schlüsselverschlüsselungsschlüssel (KEK), nicht zwingend den verpackten Inhaltsschlüssel (CEK). Implementierungen MÜSSEN gleiche KEK- und CEK-Längen unterstützen. Wenn sie unterschiedliche Längen unterstützen, MUSS die KEK mindestens so lang wie die CEK sein. RFC 3657 zieht somit eine Kodierungs- und Kompatibilitätsgrenze, statt eine einheitliche Schlüssellänge für die ganze Kapsel vorzuschreiben. RFC 3657 RFC 3394

Für die Fähigkeitsmeldung gilt eine dritte Kodierung

RFC 3657 regelt außerdem, wie ein S/MIME-Client Camellia-Unterstützung in SMIMECapabilities meldet. Die Fähigkeits-OID wird von einem NULL-Parameter begleitet. Das widerspricht nicht den fehlenden Parametern des Wrap-Bezeichners: Es handelt sich um unterschiedliche ASN.1-Strukturen mit anderer Bedeutung. Auch auf der Leitung ist NULL nicht dieselbe Darstellung wie ein fehlender Parameter. RFC 3657 führt DER-Kodierungen für alle drei Schlüssellängen auf, damit sich die gemeldete Form genau vergleichen lässt. RFC 3657 RFC 2633

Die Fähigkeitsliste ist signiert und nach Präferenz geordnet, bildet aber nur einen Teil der unterstützten Funktionen ab. Sie fließt zusammen mit privaten Vereinbarungen, Nutzerwünschen und rechtlichen Einschränkungen in eine spätere Entscheidung ein. Sie ist weder ein Live-Handshake noch ein Test der aktuellen Empfängerkonfiguration oder ein Beleg dafür, dass eine bestimmte Nachricht Camellia verwendete. Für den tatsächlich ausgewählten Vorgang muss man die Inhaltsverschlüsselungs- und Schlüsselverwaltungsfelder der Kapsel prüfen, nicht nur eine frühere Fähigkeitsmeldung. RFC 3657

Interoperabilität hängt von der Trennung dieser Grenzen ab

Eine Interoperabilitätsprüfung sollte die drei Kontexte getrennt vergleichen. Bei der CBC-Inhaltsverschlüsselung sind Kennung, Schlüssellänge und der vorhandene 16-Oktett-IV zu prüfen. Beim Key Wrap geht es um fehlende Parameter und darum, ob die tatsächlichen KEK- und CEK-Längen zur erklärten Unterstützung der Implementierung passen. Bei der Fähigkeit sind der signierte DER-Wert – einschließlich NULL – und die Präferenzreihenfolge abzugleichen. Werden die Kontexte vermischt, kann es zu unterschiedlichen Interpretationen oder Auswahlen kommen, obwohl alle Systeme dieselbe Chiffre zu unterstützen behaupten.

RFC 3657 legt fest, dass Camellia Key Wrap dem Verfahren aus RFC 3394 folgt und dabei AES durch Camellia ersetzt; beide haben eine Blockgröße von 128 Bit. Der Standard-Anfangswert für die Integritätsprüfung ist die Konstante A6A6A6A6A6A6A6A6. Wird dieser Wert beim Entpacken nicht wiederhergestellt, gibt der Empfänger einen Fehler zurück und darf keine Schlüsseldaten ausgeben. Für anwendungsspezifische Integritätsbereiche sind alternative Anfangswerte vorgesehen. Diese Prüfung bezieht sich auf die verpackten Schlüsseldaten im spezifizierten Verfahren; sie authentifiziert weder den Absender noch den CMS-Inhalt oder die Berechtigung eines Nutzers, mit entschlüsselten Daten zu handeln. RFC 3657 RFC 3394

Dies ist eine historische Rekonstruktion eines Kodierungsvertrags, keine aktuelle Sicherheitsempfehlung und keine Verbreitungsstudie. Das CMS-Algorithmenregister und spätere Profile liefern Kontext, beweisen aber weder, welche Produkte RFC 3657 implementierten, noch wie häufig das geschah. Die engere Lehre bleibt: Ein Algorithmusbezeichner ist ein typisiertes Protokollfeld. OID, Parameterpräsenz und umgebende Struktur müssen zusammen gelesen werden. RFC 3370 RFC 8419

Quellen