Zusammenfassung

  • MIME-Base64 ist eine reversible Transportdarstellung für Körperdaten; Vertraulichkeit, Integrität, Authentizität, Berechtigung und sichere Ausführung gehören nicht zu ihrer Aussage.
  • Ein belastbarer Beleg hält Eingabe, MIME-Geltungsbereich, Profil, Decoderregeln, Ausgabebytes und unabhängige Sicherheitsprüfungen getrennt fest.

In einer Sicherheitsprüfung steht ein API-Schlüssel als langer Base64-Block in einer Protokolldatei. Das Team nennt ihn „verschlüsselt“, weil er nicht sofort lesbar ist. Ein Standarddecoder zeigt den Schlüssel ohne Passwort und ohne Angriff. Die Zeichenfolge war Verpackung, nicht Schutz.

Genau diese Grenze macht die Entstehung von MIME interessant. Nathaniel Borensteins IETF-Profil führt fünfzehn RFCs auf, darunter RFC 2045, 2046 und 2049. Ein Beitrag des Grinnell College von 2013 beschreibt seine MIME-Arbeit bei Bellcore und die erste MIME-Nachricht von 1992 mit Foto und Audiodatei. Die technische Aufgabe war, neue Datenarten zuverlässig über durch beschränkte Mailwege zu bewegen. Eine Zugriffssperre war es nicht.

Eine klar begrenzte Transportaussage

RFC 2045 weist Content-Transfer-Encoding zwei Informationen zu: die auf den Körper angewandte Umwandlung und den Bereich der resultierenden Darstellung. 7bit, 8bit und binary sind Identitätstransformationen. Quoted-printable und Base64 überführen Eingaben in Material, das einen auf sieben Bit begrenzten Transport übersteht.

Für eine gültige Folge liefert die deklarierte Transformation genau eine Bytefolge oder das Ergebnis „ungültig“. Diese Eindeutigkeit ist für Interoperabilität wertvoll. Zugleich dürfen Encoder verschiedene gleichwertige Darstellungen erzeugen. Der Wert sagt über den Medientyp nichts aus, außer was sich aus Algorithmus oder Transportanforderung ergibt.

Ein erfolgreiches Decodieren belegt deshalb nur: Diese Implementierung hat unter diesen Regeln diese Darstellung angenommen und diese Bytes erzeugt. Wer die Bytes erstellt hat, ob sie vorher verändert wurden, wer sie lesen darf und ob sie ungefährlich sind, bleibt offen.

Der MIME-Bereich gehört zum Beleg

Die Oberfläche zeigt einen Anhang, die Nachricht enthält jedoch verschachtelte Entitäten. Ein Transferfeld im Nachrichtenkopf gilt für den Nachrichtenkörper; innerhalb einer Entität gilt es nur für deren Körper. Zusammengesetzte Typen wie multipart und message unterliegen zusätzlichen Regeln. Ohne die genaue Grenze ist die Verarbeitung nicht reproduzierbar.

Rohmail, Base64-Abschnitt und decodierter Anhang sind drei mögliche Beweisobjekte. Ein Gateway kann Zeilenumbrüche ändern, ohne die Ergebnisbytes zu verändern. Zwei verschiedene Absender können dieselben Bytes senden. Wer nur das Ergebnis aufbewahrt, verliert Herkunft; wer nur Text vergleicht, verwechselt Formatunterschiede mit Inhaltsunterschieden.

Der Medientyp folgt als eigener Schritt. RFC 2046 empfiehlt für application/octet-stream, die Transfercodierung rückgängig zu machen und das Speichern anzubieten oder die Daten einem ausdrücklich gewählten Prozess zu übergeben. Decodieren ist kein Ausführungsbefehl. Dateiname und Content-Type sind Verarbeitungshinweise, keine kryptografische Identitätsprüfung.

Base64 braucht ein benanntes Profil

RFC 4648 behandelt Abweichungen, die der bloße Name offenlässt: Zeilenumbrüche, Padding, alphabetfremde Zeichen und die Wahl des Alphabets. MIME erlaubt bestimmte ignorierte Zeichen; ein anderes Protokoll kann Zurückweisung verlangen. Base64url verändert das Alphabet und ist nicht dasselbe Format.

Auch Kanonizität zählt. Sind nicht signifikante Padding-Bits nicht null, können verschiedene Texte zu denselben Bytes führen. Ignorierte Zeichen können als verdeckter Kanal dienen, Vergleiche umgehen oder Implementierungsfehler auslösen. Ein reiner Ausgabehash zeigt nicht, was akzeptiert wurde; ein reiner Eingabehash zeigt nicht, ob zwei Formen denselben Inhalt tragen.

Darum müssen Spezifikation, Bibliotheksversion und Regeln für Leerraum, Fremdzeichen und Padding protokolliert werden. Eine Umstellung auf striktes Decodieren verändert die Annahmegrenze, auch wenn der Geschäftsprozess unverändert aussieht.

Optische Verschleierung ist keine Vertraulichkeit

RFC 4648 stellt klar: Basiscodierung kann erkennbare Informationen optisch verbergen, bietet aber keine rechnerische Vertraulichkeit und fügt Klartext keine Entropie hinzu. Es gibt weder geheimen Schlüssel noch Zugriffsentscheidung. Wer die Zeichenfolge erhält, kann die öffentliche Umkehrfunktion anwenden.

Integrität und Authentizität entstehen ebenfalls nicht. Geänderte Bytes lassen sich ebenso leicht neu codieren. Ein Hash bestätigt Gleichheit mit einem bekannten Wert, nicht dessen Urheber. Signatur oder MAC binden Bytes nach festgelegten Regeln an einen Schlüssel; wem dieser Schlüssel zugeordnet wird, ist eine weitere Entscheidung. Authentifizierte Verschlüsselung kann Schutz liefern, muss aber mit einem eigenen Prüfergebnis belegt werden.

Base64 ist deshalb nicht als Sicherheitsfunktion gescheitert. Es war nie eine. Der Fehler entsteht, wenn ein Datenmodell nach decoded=true auch encrypted, verified oder safe setzt.

Ein sechsteiliger Decodierbeleg

Erstens wird der Hash der empfangenen Darstellung samt MIME-Grenzen gespeichert. Zweitens wird das Profil genannt. Drittens werden Decoder, Version und Toleranzen dokumentiert. Viertens folgen Annahme oder Ablehnung sowie der Hash der Ausgabebytes. Fünftens wird der Medientyp nach sicherer Richtlinie behandelt, ohne automatisch auszuführen. Sechstens werden Signatur, Verschlüsselung, Transportauthentisierung und Berechtigung getrennt angefügt.

Ohne Signaturprüfung bleibt das Feld leer. Schützt TLS nur eine Teilstrecke, wird nur diese Teilstrecke vermerkt. Ein unbekannter Typ bleibt unbekannt. Leere Felder sind keine mangelhafte Datenqualität, sondern die ehrliche Grenze der Messung.

MIME wurde tragfähig, weil Borenstein und seine Mitautoren Aufgaben sauber trennten. Diese Disziplin gilt weiter: Base64 darf eine reversible Darstellung belegen; Vertrauen darf nur eine tatsächlich ausgeführte Vertrauensprüfung belegen.