RFC 2104：HMACが標準化したのは構成であり、信頼判断ではない

要約

1997年に必要だったのは、新しいハッシュ関数そのものではなかった。MD5やSHA-1の高速な実装はすでに存在した。課題は、秘密をメッセージの前後に安易に付けるのではなく、既存コードを生かしながら分析可能な鍵付き認証を作ることだった。

RFC 2104は、その課題を小さな共通部品にまとめた。成功の理由は、計算規則を厳密にしながら、その結果をどう信頼判断へ使うかを別の層に残した点にある。

RFC 2104では、ハッシュ関数をH、入力ブロック長をB、出力長をLとする。Bより長い鍵はまずHでLバイトに縮め、短い鍵はBまでゼロで埋める。そこで、0x36を繰り返したipadと、0x5cを繰り返したopadという異なる定数を用いる。

式はH((K xor opad) || H((K xor ipad) || text))である。内側では鍵から導いたブロックの後にメッセージを置く。外側では別の鍵由来ブロックの後に内側のダイジェストを置く。Hの圧縮処理を書き換える必要はない。

既存実装と性能を維持し、鍵処理を単純にし、解析と将来の置換を可能にする。それが仕様の狙いだった。一方で、textの業務上の意味、符号化、送信資格、検証後の動作は定めていない。

短いメッセージが多い場合、内側と外側の鍵ブロックを処理した中間状態を保存すれば、毎回二つの圧縮処理を省ける。このローカルな最適化は相互運用性に影響しない。

ただしRFC 2104は、その状態を秘密鍵と同様に保護するよう求める。派生値は、形がKと違っても再利用可能な権限を保持し得る。元の鍵ファイルだけを守り、中間状態を漏らす運用は境界を守ったことにならない。

鍵の乱数性、安全な交換、保管、更新も式からは生まれない。文書はそれらと正しい実装を必須条件として挙げる。HMACは計算を標準化したが、鍵管理を自動化したわけではない。

HMAC出力の左端tビットだけを送る切り詰めも認められた。長さは推測成功率に関わるため、プロトコルが明示しなければならない。「HMAC検証成功」という記録には、アルゴリズム、鍵IDと世代、認証したバイト列、タグ長が伴って初めて範囲が分かる。

HMACは二つのJSONやUnicode文字列が同じ意味か判断しない。フィールド順、空白、文字コード、正規化が違えばタグも違う。逆に、両端が誤ったフィールド集合を同じように処理すれば、意味上の欠陥を残したままタグは一致する。正規化はMACの前に設計すべき別の規則である。

共有対称鍵は帰属にも限界を作る。正当な鍵保有者は全員、有効なタグを生成できる。したがって検証は、その鍵領域の誰かが生成できたことを示しても、人物、プロセス、ホストを一意に選ばない。デジタル署名でも否認防止でもない。

同じ1997年のRFC 2202は、HMAC-MD5とHMAC-SHA-1の既知入力・出力を示した。独立実装はバイト境界で結果を比較でき、文章と数式は相互運用の検査点になった。

しかし合格が示すのは選ばれたケースの一致である。全長、エラー経路、時間差攻撃を避ける比較、本番の鍵選択、並行処理、リプレイ状態までは証明しない。局所的な適合性をシステム全体の安全証明へ膨らませてはならない。

RFC 2104はMD5とSHA-1を当時の例として挙げつつ、Hを抽象化した。後のRFC 4868はIPsec向けにHMAC-SHA-256、-384、-512を定義した。RFC 6151はMD5評価を更新し、新規プロトコルでHMAC-MD5を使わないよう求めた。

構成は初期アルゴリズムより長く生きた。ただし、識別子、ネゴシエーション、コード、ポリシー、試験、鍵更新は人と組織が移行させる必要がある。交換しやすい接口は負担を減らすが、移行の決定までは実行しない。

NISTのFIPS 198-1への展開は制度的な広がりを示す。構造が長寿命でも、最初のハッシュ選択が永久に安全になるわけではない。

古いメッセージと古いタグは再び検証に成功し得る。鮮度にはnonce、カウンター、時刻窓などの状態が必要だ。認可には、認証済み文脈と許可操作を結ぶ規則が要る。秘匿には暗号化、配送や確定効果には後続の記録が要る。実装の正しさは既知ベクトルだけでは足りない。

RFC 2104が残したのは、境界を説明できる薄く厳密な部品だった。2回のハッシュ処理はMACを再利用可能にした。信頼はその周囲で組み立て続けなければならない。