要約

  • MIMEのBase64は本文を可逆な転送表現に変えるが、機密性、完全性、真正性、権限、安全性を付与しない。
  • 検証可能な記録には、受信表現、MIME範囲、適用プロファイル、デコーダー方針、出力バイトのハッシュ、独立したセキュリティ結果が必要だ。

障害調査で、二つのメールから取り出したBase64文字列が一致しなかった。片方には改行があり、もう片方にはない。担当者は別ファイルだと判断したが、デコード後のバイト列は同じだった。ところが次は、同じバイトだから同じ送信元だと結論づけた。最初は表現を内容と混同し、次は内容を来歴と混同したのである。

MIMEは、このような層の違いを扱うための仕組みだった。Nathaniel BorensteinのIETFプロフィールには、RFC 2045、2046、2049を含む15本のRFCが掲載されている。Grinnell Collegeの2013年の記事は、BellcoreでのMIME開発と、写真・音声ファイルを含む1992年の最初のMIMEメッセージを紹介する。解決したのは、従来のメール経路では壊れやすかったデータを相互運用可能に運ぶ問題であり、閲覧者を制限する問題ではない。

転送符号化が答える範囲

RFC 2045によれば、Content-Transfer-Encodingは本文に施した変換と、変換後の表現が属するデータ領域を示す。7bit、8bit、binaryは恒等変換で、quoted-printableとBase64は入力を制約のある7ビット転送路に載せられる形へ変える。

有効な入力に対して、宣言された変換は一つの明確なバイト列を返すか、不正な列として拒否する。これは重要な保証だ。しかしエンコーダーは同じ入力から複数の等価表現を作ってよい。また転送符号化の値は、変換方法または転送要件以外の媒体型を意味しない。

したがって、成功ログが裏付けるのは「この実装が、この規則で、この実体を受理し、このバイト列を得た」という事実である。作成者、改ざんの有無、閲覧権限、実行してよいかどうかは含まれない。

画面上の添付ファイルは一枚でも、証拠は一枚ではない

MIMEは入れ子構造を持つ。メッセージヘッダーにある転送符号化はメッセージ本文に、各実体にあるものはその実体の本文だけに適用される。multipartやmessageのような複合型にはさらに制約がある。どの境界を入力にしたかを失えば、後から同じ処理を再現できない。

生メール、符号化された部分、デコード後の添付は別の証拠対象だ。ゲートウェイが行折り返しを変えても、出力バイトは変わらない場合がある。逆に、送信者も経路も違うメッセージが同じバイトを運ぶこともある。出力ハッシュだけでは来歴が消え、文字列だけでは意味の同一性を見誤る。

媒体型の判断も別工程である。RFC 2046はapplication/octet-streamについて、転送符号化を元に戻して保存を提案するか、利用者が選んだ処理へ渡すという慎重な扱いを示す。デコード成功は自動実行の許可ではない。拡張子やContent-Typeも、暗号学的な身元証明ではない。

どのBase64かを記録する

RFC 4648は、「base64」という名前だけでは改行、パディング、アルファベット外文字、使用する文字集合が決まらない問題を整理した。MIMEでは特定の改行や無視規則があるが、別の仕様は拒否を求めることがある。base64urlは文字集合が異なり、通常のBase64と同じではない。

正規表現にも注意が要る。末尾の意味を持たないビットがゼロでなければ、異なる文字列が同じバイトに戻りうる。無視される文字は秘密の通信路に使われたり、文字列比較を回避したり、実装不具合を刺激したりする。出力だけを残すと入力の非正規性を検証できず、入力だけを残すと同じ内容を別物として数える恐れがある。

ログには、参照仕様、デコーダーの版、空白・不正文字・パディングの扱いを含める必要がある。厳格モードへの変更は、業務画面が同じでも受理境界を変えるからだ。

見えにくさと機密性は違う

RFC 4648のセキュリティ考慮事項は、基数符号化がパスワードのような情報を見た目には隠しても、計算上の機密性を与えず、平文にエントロピーを加えないと明記する。秘密鍵もアクセス判定も存在せず、表現を取得した人は公開手順で戻せる。

完全性や真正性も同様だ。別のバイトを再符号化することは容易である。ハッシュは既知値との一致を示しても、その既知値を誰が作ったかは示さない。署名やMACは鍵との関係を検証するが、その鍵を誰に信頼させるかは別の判断だ。認証付き暗号が使われたなら、その検証結果も証拠層に記録する必要がある。

Base64を批判する必要はない。Base64は担当した仕事をしている。危険なのは、デコーダーの成功をデータモデルがencrypted、verified、safeへ読み替えることだ。

六段階のデコード受領書

第一に、受信した符号化表現のハッシュとMIME実体境界を保存する。第二に、MIME Base64、base64urlなど適用プロファイルを特定する。第三に、実装と受理方針を記録する。第四に、成功・拒否と出力バイトのハッシュを残す。第五に、媒体型と安全な取り扱いを判断する。第六に、署名、暗号、転送認証、権限の結果を別欄に結び付ける。

署名を検証していないなら空欄にする。TLSが一つの区間しか守っていないなら、その区間だけを書く。種類が分からない出力を拡張子で確定しない。

BorensteinらのMIMEが長く使われた理由の一つは、協調する機能を混ぜなかったことにある。Base64にも同じ節度を適用すればよい。可逆な表現は証明できる。信頼は、信頼を検証した記録からのみ生まれる。