HMAC（Hash-based Message Authentication Code）は1997年2月、IBMのMihir Bellare、UCSDのRan Canetti、MITのHugo Krawczykが共同提案し、RFC 2104として標準化されたメッセージ認証コード方式です。MD5やSHA-1などの一方向ハッシュ関数と秘密鍵を組み合わせ、メッセージの完全性と送信者の真正性を同時に検証できます。TLSのレコード保護、IPsecの認証ヘッダ、JWTのHS256、AWS APIのSigV4署名、OAuth 2.0のクライアント認証など、現代のインターネット通信のあらゆる場面で「鍵付きハッシュ」の標準として採用されています。
この記事の目次
- 二重ハッシュで成り立つ仕組み
- RFC 2104誕生の背景
- 現代APIと認証で見かける場面
- AES-GMAC・KMACなど他MACとの比較
- まとめ
二重ハッシュで成り立つ仕組み
HMACの定義はHMAC(K, m) = H((K' ⊕ opad) ‖ H((K' ⊕ ipad) ‖ m)) というシンプルな式です。K'は秘密鍵をブロックサイズ（SHA-256なら64バイト）に合わせてパディング（短ければ0埋め、長ければハッシュで縮める）した値、ipadは0x36の繰り返し、opadは0x5cの繰り返しという定数で、内側ハッシュと外側ハッシュで異なる鍵派生を行う点が肝です。この二重構造があるおかげで、Length extension攻撃のような単純ハッシュ連結の脆弱性を回避できます。
HMAC自体はハッシュ関数Hに依存しないラッパー方式で、HMAC-MD5、HMAC-SHA1、HMAC-SHA256、HMAC-SHA3-256、HMAC-Blake2bなど任意のハッシュと組み合わせて使えます。安全性証明は内側ハッシュの擬似ランダム関数性と外側ハッシュの一方向性に依拠しており、ベースとなるハッシュが衝突耐性を失っても、HMAC自体は擬似ランダム関数として動き続けることが知られています。現在の実務では、SHA-256と組み合わせたHMAC-SHA256が最もよく使われる組み合わせです。
RFC 2104誕生の背景
1990年代前半、IPsecの設計が進む中で、メッセージ認証コード（MAC）の標準化が課題になっていました。当時主流だったMD5やSHA-1は一方向ハッシュとして設計されており、そのままでは鍵付き認証に使えません。単純にハッシュにシークレットと本文を連結する素朴な方式（secret prefix MAC）は、Merkle–Damgård構造のハッシュではLength extension攻撃に脆弱で、追加データを偽造できる問題が知られていました。
Mihir Bellare、Ran Canetti、Hugo Krawczykの3人は1996年にCRYPTO学会で論文「Keying Hash Functions for Message Authentication」を発表し、HMAC構造を提案しました。1997年2月にRFC 2104として標準化され、2002年にはFIPS 198として米国政府標準にも採用。IPsec、TLS（1.0以降）、SSH、SNMPv3、Kerberosなど主要プロトコルの認証層に組み込まれていきました。現在も多くのRFCがHMAC-SHA256やHMAC-SHA384を擬似ランダム関数として参照しています。
現代APIと認証で見かける場面
HMACは現代のクラウドAPIで広く使われています。AWS Signature Version 4は、シークレットアクセスキーからHMAC-SHA256を4回連鎖させて日付・リージョン・サービス別の鍵を導出し、リクエスト全体に署名を付けます。GitHubやStripeなどのWebhookは、ペイロード本文にHMAC-SHA256を施した値をHTTPヘッダで送り、受信側が同じ鍵で再計算して送信元を確認します。JWTのHS256はヘッダ・ペイロード連結をHMAC-SHA256で署名する仕組みで、シンプルなWeb API認証で広く採用されています。
ワンタイムパスワード生成のTOTP（RFC 6238）もHMAC-SHA1ベースで、現在時刻を30秒単位に区切ったカウンタを共有秘密鍵でHMAC計算し、下位31ビットから6桁数字を切り出す仕組みです。Google AuthenticatorやMicrosoft Authenticatorはこの方式を実装しています。さらにTLS 1.2/1.3の鍵導出関数HKDF（RFC 5869）も内部でHMACを2段使うExtract-and-Expand構造を採用しており、「共有秘密から目的別鍵を派生させる」標準的な手段としても君臨しています。
AES-GMAC・KMACなど他MACとの比較
MAC方式にはHMAC以外にもいくつかの選択肢があります。AES-GMACはGalois/Counter Modeの認証部分のみを抜き出したMACで、TLS 1.3のAEADスイートではAES-GCMの一部として使われます。Poly1305はDaniel J. Bernsteinが設計した高速MACで、ChaCha20と組み合わせたChaCha20-Poly1305がGoogleとIETFで広く採用されています。AES-CBCベースのCMAC（NIST SP 800-38B）はFIPS認定が必要な金融・政府用途で使われます。
近年はSHA-3（Keccak）ベースのKMAC（NIST SP 800-185、2016年）も標準化されましたが、実装の普及度ではHMAC-SHA256が依然として圧倒的多数派です。理由は単純で、SHA-256ハードウェア命令がIntel/AMD/ARMにあらゆる世代で搭載されており、JWTやAPI署名などのテキスト交換プロトコルでは互換性こそが価値だからです。HMACは30年近く前の設計でありながら、安全性とシンプルさの観点で今も第一選択の地位を譲っていません。
まとめ
HMACはハッシュ関数を鍵付きMACへ変換する標準的なラッパー方式として、四半世紀にわたり安全性とシンプルさを両立してきました。JWTやAPI署名、TOTP、HKDFなど現代インフラの認証層に組み込まれており、Poly1305など新しいMACが登場した今も第一選択の座を維持し続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント