HMACをいつどのように使用しますか？
私は wikipediaのHMAC を読んでいて、いくつかの点で混乱していました。
- HMACはどこで使用しますか？
- なぜハッシュの重要な部分なのですか？
- 誰かが「長さ拡張攻撃」をうまく使用したとしても、それは攻撃者にとってどのように役立ちますか？
メッセージ認証コード（MAC） は、MACアルゴリズムによってメッセージと秘密鍵から生成されます。 MACの重要な特性は、秘密鍵を知らずにメッセージのMACと秘密鍵を生成することが不可能であることです。異なるキーによって生成された同じメッセージのMACは、無関係に見えます。他のメッセージのMACを知っていても、新しいメッセージのMACの計算には役立ちません。
[〜＃〜] hmac [〜＃〜] は、 ハッシュ関数 に基づくMACです。基本的な考え方は、キーとメッセージを連結し、それらを一緒にハッシュすることです。暗号化ハッシュが与えられた場合、それが何であるかを見つけることは不可能であるため、ハッシュ（またはそのようなハッシュのコレクションでさえ）を知っていても、キーを見つけることはできません。基本的なアイデアは、 length extension attack が原因で一部うまくいきません。そのため、実際のHMACの構築はもう少し複雑です。詳細については、暗号化スタック交換で hmacタグを参照してください 、特に H（k || x）が安全なMAC構造ではない理由/ 、 H（k || length || x）は安全なMAC構築ですか？ および HMAC vs MAC functions 。 MACを定義する方法は他にもあります。たとえば、 [〜＃〜] cmac [〜＃〜] などのブロック暗号に基づくMACアルゴリズムがあります。
MAC authenticatesメッセージ。アリスがメッセージとMACを見て、関連する秘密鍵を知っている場合、自分でMAC計算を実行することにより、MACが鍵を知っているプリンシパルによって生成されたことを確認できます。したがって、メッセージに正しいMACが添付されている場合、ある時点でこのメッセージが秘密鍵の所有者によって見られたことを意味します。 MACは秘密鍵に基づくsignatureであり、RSAベースのスキームなどの公開鍵暗号に基づく署名スキームと同様の保証を提供します。秘密鍵。
たとえば、アリスが自分の秘密鍵を自分で保持し、クラウドサーバーまたは他の信頼性の低いストレージメディアに保存するメッセージのMACを計算するためにのみ使用するとします。後でメッセージを読み返して、正しいMACが添付されていることを確認すると、これは過去に保存したメッセージの1つであることがわかります。
HMAC自体はメッセージの整合性を提供しません。整合性を提供するプロトコルのコンポーネントの1つにすることができます。たとえば、Aliceが複数のファイルの連続するバージョンを、MACとともに信頼できないメディアに格納するとします。 （ここでも、Aliceだけが秘密鍵を知っていると仮定します。）彼女が正しいMACでファイルを読み戻した場合、彼女が読み取ったものは、以前に保存したファイルのバージョンであることがわかります。ストレージメディアを制御している攻撃者は、古いバージョンのファイルまたは別のファイルを返す可能性があります。このシナリオでストレージの整合性を提供する1つの可能な方法は、MACが計算されるデータの一部としてファイル名とバージョン番号を含めることです。アリスは、失効したデータが与えられていないことを確認するために、各ファイルの最新バージョン番号を覚えておく必要があります。整合性を保証する別の方法は、アリスが各ファイルのMACを記憶することです（ただし、この特定のシナリオでは、ハッシュも同様に機能します）。
¹ 「不可能」は、現実的に可能なよりもはるかに高い計算能力を必要とする場合と同様です。
HMACは、いくつかのデータと共に送信されることが多い計算された「署名」です。 HMACは、データが変更または置換されていないことを確認（認証）するために使用されます。ここに隠喩があります：
写真が含まれているパッケージをサラに郵送します。あなたは彼女がパッケージを開けて写真を見ることを期待します。近い将来のある時点で、あなたは彼女がその写真を入れたパッケージを送り返すことを期待します。彼女が同じ写真をパッケージに戻すことが重要です。あなたは彼女が少しでも変更された写真をあなたに送り返さないか、またはそれを別のものと取り替えないことを絶対に確認する必要があります。これらのパッケージは何百枚もあり、さまざまな写真が毎日出ています。彼女が写真の小さな部分を変更したかどうか（彼女が顔に小さな小物をエアブラシで吹き付けた場合など）がわかるほど詳細に写真を覚えることはありません。
できることは次のとおりです。荷物を送る前に、写真の別のコピーを小さな鍵付きの箱に入れます。キーを保管してください。封をした小さな箱を、郵送する元の写真と一緒にパッケージの中に入れます。ロックされたボックスをパッケージから取り出さないことを彼女が知っていると想定します。彼女からパッケージを受け取ったら、それを開いて、写真をテーブルに置きます。ロックされたボックスを開き、コピーを削除して、2つを比較します。それらが同じである場合、彼女は写真を変更していません（「本物」です）。ロックされたボックスがパッケージに含まれていない場合、または鍵で開けられない場合は、彼女が何か悪意のあることを行ったと想定し、パッケージ全体をゴミ箱に捨てます。ここの美しさは、あなたが最初に彼女に送ったものについて何も「覚えておく」必要がないことです。写真の正当性を保証するために必要なものはすべてパッケージの中に戻ってきます。
上記の例では、小さなロックされたボックスがHMACを表しています。あなたの鍵はHMACの鍵です。写真は、HMACを適用するデータです。
上記はあなただけが鍵を持っている往復の比喩です。別の状況で、パッケージをトミーに頻繁に送信するとします。せんさく好きなメールキャリアがパッケージを開いて写真を入れ替えたり、変更したりするのではないかと心配しています。ロックされたボックスで同じことを行いますが、この場合は、キーのコピーをトミーに渡して、パッケージを受け取ったときに同梱されているロックされたボックスを開き、写真を自分で比較できるようにします。受け取ったときに写真が異なるとわかった場合、彼の鍵が箱を開けない、または箱が見つからない場合、彼は何かが怪しいことを知っています。
上記の比喩は、なぜHMACが必要なのかを説明していますが、HMACの機能はそれほどではありません。メタファーをもう一度変更して、それらがどのように機能するかに近づけましょう。
パッケージの精神的なイメージを写真と一緒に保管しましょう。郵送し、以前と同じようにもう一度受け取り、写真が変更されたり、受信者によって交換されたりしないように、または往復中に確認します。
パッケージを閉じて郵送する前に、写真のコピーを作成します。今回はロックされたボックスはありません。代わりに、液体化学物質の調合剤でコピーにブラシをかけます。この混合物のレシピ（キー）を知っているのはあなただけであり、コピーにブラシをかけるときはいつでも、まったく同じブラシストロークを使用します。混合物は写真のコピーを渦巻かせ、ぼかしてモダンアートに似たものにします。それをHMACと呼びましょう。乾燥後の外観は正確にはわかりませんが、同じレシピと同じブラシストロークで2つの同一の写真をブラッシングすると、結果のHMACは同じように見えます。そこで、乾燥したHMACを元の写真と一緒にパッケージに入れ、サラに送ります。
サラからパッケージを返却すると、元の写真が変更されていないことを望み、作成して同梱したHMACであることが予想されます。パッケージから写真を取り出してコピーし、そのコピーで別のHMACを作成します（混合/ブラシストロークを適用します）。作成したHMACとパッケージに戻ってきたHMACを比較します。それらが同一であれば、サラとメールキャリアが写真を変更していないことを確認できます。
サラが写真を変更した場合、HMACは同一ではなくなります。サラがHMACを変更した場合、HMACは同一ではなくなります。サラが写真を変更し、新しいHMACを作成しようとした場合、HMACは同一ではありません（彼女はあなたのレシピを知りません）。
したがって、写真（データ）が本物であるかどうかがわかります。これは、HMACが使用される目的とまったく同じです。
短い答えは「HMACはPKIの代わりに対称鍵を使用してデジタル署名を提供する」です。基本的に、公開鍵/秘密鍵、信頼のルート、および証明書チェーンの複雑さを処理したくない場合でも、HMACで信頼できるデジタル署名を保持できます。 HMACは、プライベート/パブリックペアではなく、対称キー暗号化と事前共有秘密に依存しています。欠点は、一般的に対称キー暗号化と同じです。秘密キーの配布と保護について心配する必要があります。
１。必要なときにいつでもHMACを使用しますintegrity維持されるデータ（および信頼性）
２。鍵はHMACの一部です。これは、2者間でのみ知られている共有秘密であり、HMACを作成できるのは2者だけであり、他の誰も作成できないためです。 （保証authenticity）
３。長さ拡張攻撃はHMACで不可能です。一方、MACは単純にメッセージにキーを追加するため、影響を受けやすくなっています。 HMACは、MACに対するこの攻撃を克服するために導入されました。
HMACSは、2つの「完全性」と「信頼性」を確認する必要がある場合に使用されます。たとえば、ハッシュとともにデータの一部が送信されるシナリオを考えてください。メッセージのハッシュを再計算し、受信したハッシュと比較することで、メッセージの整合性を確認できます。ただし、メッセージとハッシュが、あなたが知っている/信頼できる誰かによって送信されたかどうかは、はっきりとはわかりません。 HMACSを使用していた場合は、自分と信頼できる関係者だけが知っている秘密鍵を使用してHMACを再計算し、それを受信したHMACと比較することができます。つまり、「真正性」の目的に役立ちます。
前に述べたように、キーの機密性により、HMACが信頼できる当事者によって計算されたことが保証されます。
HMACSはキー付きハッシュではありません。 HMACSではなくキー付きハッシュを使用した場合、長さ拡張攻撃が可能です。詳細については、 this を確認してください。
[編集]
以下のコメントに回答するように編集された回答：-「キーがメッセージに含まれている理由がまだわかりません。パーティーの公開キーがわかりませんか？公開キーがわかっている場合、メッセージではなく、なぜキーがメッセージに含まれているのですか。既知のキーを使用していますか？キーがわからない場合、なぜそのパーティーを信頼するのですか？」
- キーはメッセージ内にありません。キーは、メッセージからHMACを生成する際にusedです。 HMACSの生成に使用される鍵は、誰の「公開鍵」でもありません。 2つの当事者間で共有される秘密のようなものです。 REST AWSのAPI認証方法をチェックして、URL署名にHMACSがどのように使用されるかを理解することができます。