署名されたS3 URLの有効期限の目的は何ですか？
S3では、署名付きURLを介してメディアのリクエストを認証できます。このURLには有効期限を含めることができます。有効期限が切れると、URLは無効になります（ http://docs.aws.Amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#RESTAuthenticationQueryStringAuth ）。 URL署名がHMAC-SHA1（ブルートフォースで実行できないと思いますか？）によって生成されるとすれば、有効期限のポイントは何ですか？総当たり攻撃を防ぐためですか（つまり、メディアURLのセキュリティを強化するためですか）？または、URLは有効期限に関係なく安全であり、有効期限はドメイン固有の有効期限を提供する方法として提供されます（つまり、銀行の明細書には1時間の有効期限が与えられ、コンピューターのネットワーク要求にアクセスできる悪意のあるユーザーがアクセスできなくなる可能性があります。後で取得しないでください）。
要約すると、S3 URLの署名は有効期限に関係なく安全ですか？または、メディアを安全に保つために必要な有効期限はかなり短いですか？
有効期限は、署名付きURLを所持している人が許可されたアクションを実行するための許可の存続期間を制限するためにあります。
URLの有効期限は、HMACへの入力の1つであるため、もちろん署名を無効にしないと変更できませんが、有効期限自体は、実際の署名のセキュリティには影響しません。アルゴリズム自体：
ハッシュされるメッセージに情報を追加しますが、秘密情報は追加しません
uRLが「期限切れ」になったという事実は、ブルートフォースが計算的に実行可能であると想定した場合、悪意のあるアクターがブルートフォースすることを防止しません...私の署名シークレットがブルートフォースされたことを確認するためにS3を必要としないため。署名アルゴリズムが、同じ入力に基づいて私が行ったのと同じ出力を生成すると、勝ちます。確かに、その固有のURLは現在有効期限が切れていますが、私の署名の秘密があり、好きなURLに好きな有効期限で署名できます。
ここで私が言っていることは、署名アルゴリズムのセキュリティに欠陥があると私が思うことを意味するものではないことに注意してください。私の唯一のポイントは、有効期限が、有効期限の場合にアルゴリズムが提供するセキュリティのレベルに影響を与えないことです。コンポーネントではありませんでした。
また、明確にするために、有効期限は署名されたメッセージの一部であるため、定義により、有効期限は改ざんされにくくなっています。昨日有効期限が切れた私の有効なURLは、「明日有効期限が切れる」ように調整することはできず、その署名はまだ有効です。
あなたが言及した署名バージョン2アルゴリズムは非常に簡単です。概念的には、作成するリクエストを正規化してから、HMACで実行します。 リクエストに含まれるものは秘密ではありません、exceptは秘密鍵です。有効期限を含む要求自体（HMAC関数への入力メッセージ）には、非表示のコンポーネントはありません。 S3は同じ署名を生成できず、特定の要求（HTTP動詞、コンテンツ-MD5ヘッダー値（送信する場合）、Content-Typeヘッダー値（送信する場合）、有効期限、正規化X-Amzヘッダー（送信する場合）、最後に/${bucket}/${key}{$canonical_query_string}（これらすべての要素を連結したもの）間に\nを入れます。
S3は私の秘密を知っており（実際、すべてのAWSサービスがそうであるように、彼らは私のリクエストを検証できます）、私と同じ署名を生成しようとします。成功した場合、リクエストに署名された資格情報を持つユーザーが実際にリクエストを行うことが許可されていれば、リクエストは許可されます。
生成した署名付きURLを所有している場合は、私が署名したであろうメッセージを再現することで、その総力を発揮することができます（これを行うためにURLから必要なものすべてを既に知っています）。同じSignatureを計算します。署名付きURLであなたに与えたのは、私の秘密鍵を解読したことです。特定のリクエストと有効期限について、正しい署名は1つだけです。
もちろん、このクラッキングプロジェクトで頑張ってください。キー（およびそれに付随するシークレット）をアクティブステータスからローテーションし、数週間または数か月後に、キーをクラックする有意義な機会が得られるかなり前に無効にします。
しかし、要点は、私がHMACであるメッセージに含まれる他のすべてのコンポーネントと同様に、URLに&Expires=が表示され、元のメッセージを再現するために、そこにどのような値が入るかがわかります。署名した。有効期限が切れても、タスクが複雑になることはありません。
いいえ、有効期限は、私が渡す署名付きURLの有効期間を厳密に制御するためのものです。理論上、そのURLへの不正アクセスには一定の時間がかかります。一般に、情報の機密性が高いほど、リクエストの有効期限を短く設定する必要があります。
補足：有効期限が含まれていると、バックエンドサーバーに小さな最適化が行われます。これは自分で証明できます-有効期限がチェックされますfirst 、署名の有効性がチェックされる前。結局のところ、CPUサイクルを費やして、署名が期限切れであることを明示する有効期限を伴う署名を検証しようとしても意味がありません。 S3は、署名が有効かどうかに関係なく、有効期限が過ぎると同じ "Request has expired"エラーを返すことにより、この不要な作業を短絡させているようです。これは、有効なリクエストの有効期限を手動で変更することで確認できます。過去に設定した場合、署名は無効になりますが、「リクエストが期限切れです」というエラーが表示されます。将来に設定すると、署名も無効になりますが、表示されるエラーは署名が無効であることを示します。
また、署名バージョン4は、HMAC-SHA256の5つのネストされた反復を使用するV2よりもはるかに複雑で、さらに安全なアルゴリズムです...そして、「多くの方が良い」という誤った見方があるため、5回の反復はありません。 」
実際、このアルゴリズムの設計の影響が私に浸透するまでにはしばらく時間がかかりましたが、それはかなり素晴らしいもののようです。
レイヤーをはがすと、AWSがこのアルゴリズムを内部的に（つまりAWS内で）設計し、最小限の特権の原則に従って信頼を委任したことが明らかになります。
最も内側のHMAC反復は、「AWS4」という文字列と私の秘密で構成される秘密で署名された、今日の日付で構成されるメッセージです。それがDateKeyです。 7日間だけ有効です。 IAMの中央セキュリティリポジトリは、私の秘密とDateKeyを知っている唯一のエンティティです。
次の反復では、DateKeyの出力を使用してAWSリージョンのリテラル名（us-west-2など）に署名し、DateRegionKeyを導出します。その後、IAMはこの値を各リージョン内のサブシステムに配信できます。これにより、グローバルではなく、リージョンの私の署名を検証するために知る必要があるすべてをサブシステムが知ることができます。
次に、AWSサービス名（例：s3）がDateRegionKeyで署名され、DateRegionServiceKeyが生成されます。各リージョンで、IAMサブシステムは各サービスに対してこのシークレットを生成し、その1つのリージョン内で、サービスの署名を認証するためにサービスが知る必要があるすべてのサービスを各サービスに配信できます。
次に、文字列 "aws4_request"がDateRegionServiceKeyで署名され、私の毎日の署名鍵が形成されます。 「aws4_request」は本質的に単なる文字列なので、各サービスは、今日のリクエストの署名に使用する署名キーを（格納するのではなく）導出でき、必要な情報のみを持ち、それ以上のものはありません。
最後に、毎日の署名キーを使用して、正規化された各リクエストに署名します。
彼らが何をしたかわかりますか？
IAMコアシステム以外のシステムでは、実際の秘密を知る必要はありません。たとえば、S3リージョンのインフラストラクチャに内部違反があった場合（ただし、そうである可能性は低いですが）、攻撃者が入手できる情報は私の実際の秘密を明らかにしません-そのリージョンのS3が認識している秘密のみを明らかにします。地域のインフラストラクチャが侵害された場合、取得された認証情報は、ルートまでのチェーンの他の地域などでは役に立たなくなります。
V4アルゴリズムは、安全でグローバルに分散された秘密の署名鍵委任システムであると思われるものの中核にあり、すべてが内部的に知る必要があります。私が言うように...それはかなり素晴らしいようです。
次のシナリオで役立ちます。
たとえば、特定のユーザーだけにビデオファイルを提供したいとします。あなたは彼らがURLを共有することをより困難にしたいと考えています。
ボブはあなたのサイトにサインインし、ビデオを選択します。有効期限付きのURLを生成し、HMACで5秒に設定します。ページが1秒で読み込まれ、埋め込まれたビデオプレーヤーがAWSにリクエストを送信します。 URLはまだ有効です。
ボブはHTMLソースを見て、ビデオのURLを見つけてコピーし、友人に送信します。友達がURLを開きますが、期限が切れています。
SHA1が安全ではないと想定されていても、HMAC-SHA1はおそらく影響を受けません。 AFAIK、HMAC-MD5でも安全です。考えられるすべての既知の攻撃は、HMACではなく直接ハッシュすることを目的としています。また、SHA1の単一の衝突でさえまだ不明であり、それを見つけることは依然として非常に高価で時間がかかります。
S3 URL expについてどういうわけか、SHA1-HMACセキュリティを提供することについては言及されていません。
リンクを確認してください： 暗号化されたデータを認証するためにHMAC-MD5は安全と見なされていますか？