Zusammenfassung

  • RFC 3537 stellte aus einem Längenoktett, dem HMAC-Schlüssel und Zufallspadding einen Datensatz her, den 3DES oder AES Key Wrap aufnehmen konnte.
  • Erfolgreiches Unwrap gewann die angegebenen Bytes und prüfte Integrität, band aber keinen HMAC-Algorithmus, Zweck, Prinzipal oder Ursprung; jeder KEK-Besitzer konnte eine akzeptierte Hülle erzeugen.

Eine versiegelte Kassette kann ein Band in genau bestellter Länge liefern. Ohne Arbeitsauftrag bleibt offen, in welche Maschine es gehört. Diese Trennung zwischen Maß und Mandat bestimmte RFC 3537.

Der Proposed Standard vom Mai 2003 schloss eine Formatlücke. RFC 3217 behandelte 3DES-Inhaltsschlüssel mit Parität, RFC 3394 Eingaben in 64-Bit-Blöcken. HMAC-Schlüssel waren variabel und ohne DES-Parität. RFC 3537 ergänzte deshalb einen inneren Datensatz statt einer neuen Chiffre.

Er bestand aus LENGTH || KEY || PAD: ein Oktett Länge, entsprechend viele Schlüsseloktette und das kleinste Zufallspadding bis zum Vielfachen von acht. Beim Unwrap schnitt LENGTH den Schlüssel heraus; mehr als sieben verbleibende Padding-Oktette waren ein Fehler.

„Beliebige Länge“ löste feste Schlüsselgrößen, bedeutete aber nicht unendlich. Ein einziges Oktett trägt die Länge. Diese Grenze ist aus dem Format abgeleitet und keine ausdrücklich genannte Maximalzahl; sie bleibt dennoch die Fähigkeit der Darstellung.

Die 3DES-Variante bildete über Länge, Schlüssel und Padding eine acht Oktette lange Prüfsumme, verschlüsselte mit frischem IV, stellte den IV voran, kehrte die Oktettreihenfolge um und verschlüsselte mit 4adda22c79e82105 erneut. Die AES-Variante gab denselben Datensatz an RFC 3394 und deutete ihn erst nach dessen Integritätsprüfung. Der A-Register-Mechanismus gehört zur bestehenden RFC-3394-Geschichte; hier zählt der fehlende Typ hinter der Freigabe.

Der Datensatz enthält keinen späteren HMAC-Algorithmus, kein Protokoll, keinen Mandanten, Prinzipal, Schlüsselbezeichner, Zeitpunkt, Ablauf oder erlaubte Nachrichtenklasse. PAD ist integritätsgeschützt, aber keine Zweckangabe. LENGTH markiert das Ende der Bytes, nicht der Befugnis.

Die OIDs HMAC-with-3DES-wrap und HMAC-with-AES-wrap mit zwingendem NULL-Parameter benennen die Verpackung. Sie benennen nicht HMAC-SHA-1, HMAC-SHA-2 oder einen Dienst. Aus „AES wrap“ eine konkrete Nutzungsberechtigung abzuleiten, fügt ungebundene Politik hinzu.

RFC 2104 liefert Längenhinweise: mindestens die Hash-Ausgabelänge, gewöhnlich kein Vorteil weit über der Blockgröße. Das Unwrap wählt aber keinen Hash und erzwingt kein passendes Minimum. Strukturelle Freigabe ist keine Stärkeprüfung.

Der Sicherheitsabschnitt sagt ausdrücklich, dass Vertraulichkeit und Integrität nicht zwingend Ursprungsauthentifizierung bedeuten. Jeder mit der KEK kann eine bestandene Hülle erzeugen. Dafür braucht es authentisierte KEK-Verteilung oder eine Signatur. Das Ergebnis nennt den KEK-Bereich, nicht dessen konkreten Absender.

Eine kompromittierte KEK legt alte HMAC-Schlüssel offen und erlaubt neue gültige Hüllen. Wer eine geteilte KEK als Identität behandelt, erweitert diesen Schaden auf alle vertrauenden Abläufe. Verwahrung und Empfängerkreis bleiben eigene Nachweise.

Für 3DES ist jeder IV frisch zu erzeugen; Padding ist zufällig. Diese Zufälligkeit formt die Hülle, ist aber weder HMAC-Tag noch Nonce der späteren Operation.

Das einzige Verified Erratum ändert im Testvektor PAD von 38be62 zu be62fe, passend zum zusammengesetzten Wert. Es ist Editorial und ändert keinen Ablauf.

RFC 5652, RFC 6031, RFC 4868, RFC 5649 und NIST SP 800-38F liefern äußere Strukturen, Algorithmenbezeichner oder heutigen Kontext. Sie schreiben keinen Zweck rückwirkend in LENGTH || KEY || PAD.

Eine belastbare Kette hält Wrap-OID, KEK und Recht, Integrität, Länge, Bytes, authentisierten HMAC-Algorithmus, ID, Zweck, Prinzipal, Gültigkeit, Ausführung, Verifikation und Anwendungsergebnis auseinander. RFC 3537 löste die Wiedergewinnung, nicht die gesamte Autorisierung.

Quellen