Amazon S3のチェックサムアルゴリズムが10種類に — 規制要件で読み解く使い分けガイド

AWSAmazon S3チェックサムデータ整合性コンプライアンスセキュリティ
aws-cli/CHANGELOG.rst at v2 · aws/aws-cli Universal Command Line Interface for Amazon Web Services - aws/aws-cli github.com
Checking object integrity in Amazon S3 - Amazon Simple Storage Service Verify the integrity of objects uploaded and downloaded to Amazon S3. docs.aws.amazon.com
Efficiently verify Amazon S3 data at scale with compute checksum operation | Amazon Web Services Organizations across industries must regularly verify the integrity of their stored datasets to prot... aws.amazon.com
NIST Special Publication (SP) 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths The National Institute of Standards and Technology (NIST) provides cryptographic key management guid... csrc.nist.gov
NIST Policy on Hash Functions - Hash Functions | CSRC | CSRC NIST's Policy on Hash Functions - December 15, 2022 December 15, 2022 NIST is announcing a... csrc.nist.gov
PCI DSS v4.0 Cryptographic Requirements (AppViewX) appviewx.com

2026年4月22日リリースのAWS CLI 2.34.35で、Amazon S3にチェックサムアルゴリズムが5つ追加されました。具体的には MD5、SHA-512、XXHash3、XXHash64、XXHash128 です（2026年4月22日 AWS CLI CHANGELOG 2.34.35）。これで S3 がサポートするチェックサムは合計10種類になりました。

ここで自分が引っかかったのは「なぜそんなに種類が必要なのか」です。軽量なアルゴリズムひとつで整合性チェックすれば十分ではないか、と。でも調べていくと、これは規制要件とセキュリティ要件への対応という文脈で読むとようやく腹落ちします。

自分はIAMとKMS、それと各種コンプライアンス対応を見ることが多いので、今回は「規制要件の観点で各アルゴリズムをどう使い分けるか」という切り口で整理してみました。PCI-DSSやFedRAMPの現場では見落としがちなポイントがいくつかあったので、そこを中心に共有します。

今回追加された5つのアルゴリズム

AWS CLI 2.34.35のCHANGELOGには2つのエントリがあります（2026年4月22日 AWS CLI CHANGELOG 2.34.35）。

api-change:s3: This release adds five additional checksum algorithms for S3 data integrity (MD5, SHA-512, XXHash3, XXHash64, XXHash128) and support for S3 Inventory on directory buckets (S3 Express One Zone).

enhancement:s3: Add support for xxhash3, xxhash64, xxhash128, and sha512 algorithms to the high-level s3 commands

API レベルで5つ追加され、高レベル aws s3 コマンドにも4つが反映されています。高レベル側には MD5 が含まれていない点は後述の実機検証で触れます。

追加前から使えたもの（CRC64NVME・CRC32・CRC32C・SHA-1・SHA-256）と合わせて、以下の10種類体制になりました。

分類アルゴリズム追加の種別
非暗号学的（エラー検知）CRC32既存
CRC32C既存
CRC64NVME（デフォルト）既存
XXHash3✨ 今回追加
XXHash64✨ 今回追加
XXHash128✨ 今回追加
暗号学的（改ざん検知）SHA-1既存（非推奨）
SHA-256既存
SHA-512✨ 今回追加
MD5✨ 今回追加（レガシー互換用）

そもそもチェックサムには役割が2つある

ここは設計を考える時に一番大事なポイントなので、最初に整理しておきます。

「整合性チェック」とひとことで言っても、中身は次の2つが混ざっています。

種類守る対象代表例特性
非暗号学的ハッシュ転送・保存エラー（ビット化け）CRC32, CRC64NVME, XXHash系改ざん耐性なし、超高速
暗号学的ハッシュ改ざん（悪意ある書き換え）SHA-256, SHA-512衝突困難性あり、相対的に重い

ここは見落としがちですが、「軽量なハッシュ + リトライで十分」という戦略はエラー検知の文脈では正解で、改ざん検知の文脈では成立しません。非暗号学的ハッシュは衝突を計算可能なので、攻撃者は改ざんしたファイルに対して正しい CRC32 値を付け直せます。

S3の公式ドキュメントでも、この2種類を明確に区別しています（2026年4月時点 AWS ドキュメント）。

The CRC64NVME checksum algorithm is the default checksum algorithm used for checksum calculations.

デフォルトが CRC64NVME になっているのは、「まずは高速な非暗号学的ハッシュで転送エラーを検知する」という設計思想です。改ざん検知が要るユーザーは明示的に SHA 系を選ぶ、という位置付けになっています。

「なぜ10種類も必要か」の答えは規制要件にある

ここが今回一番深掘りしたかったところです。結論から言うと、主要な規制には具体的なハッシュアルゴリズムの指定が存在します。ここを理解していないと、S3のチェックサム機能を使っても規制準拠にならない、というケースが出てきます。

いくつか主要な規制を見ていきます。

NIST SP 800-131A（全米政府系の根元）

NIST Special Publication 800-131A Revision 2 には、連邦機関が使用できるハッシュ関数が明示されています（2019年3月 NIST SP 800-131A Rev.2）。

SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256) may be used by federal agencies for all applications that employ secure hash algorithms. … NIST encourages application and protocol designers to implement SHA-256 at a minimum for any applications of hash functions requiring interoperability.

連邦機関が使用可能なのは SHA-2 ファミリーと SHA-3 ファミリーで、最低でも SHA-256 を推奨しています。SHA-1 については、NIST Policy on Hash Functionsで2030年12月31日以降 FIPS 140 validated モジュールの historical list に移行されることが明記されています（2022年12月15日アナウンス NIST Policy on Hash Functions）。

つまり SHA-1 は2030年が実質的なデッドラインです。これは連邦政府系システムに関わる設計では必ず意識すべき点です。

FIPS 140-3（FedRAMP・FISMA・DoD の必須基準）

FedRAMPやFISMA、DoD系のシステムを扱う場合、暗号モジュールは FIPS 140-3 バリデーションが必須です。FIPS 140-3 では SHA-2 と SHA-3 のみが承認され、MD5 は非承認、SHA-1 は2030年までの経過措置という扱いになっています。

ここで押さえておきたいのは、FedRAMP Moderate/High の環境でS3を使うなら、改ざん検知の文脈では SHA-256 か SHA-512 しか選択肢がないということです。CRC系やXXHash系は非暗号学的なので、そもそも「暗号アルゴリズム」の要件に該当しません。

PCI-DSS v4.0（カード業界の要件 — ここが一番特殊）

PCI-DSS v4.0 は2025年4月1日以降 mandatory になっていますが、ここが一番ハマりポイントが多いです。単純なハッシュでは要件を満たさず、keyed cryptographic hash（鍵付きハッシュ）を要求しています（2025年頃 PCI DSS v4.0 Cryptographic Requirements - AppViewX）。

Suitable encrypted cryptographic hash algorithms named by PCI DSS v4.0 include: HMAC and KMAC with an effective cryptographic strength of at least 112 bits or CMAC and GMAC with 128 bits (NIST SP 800-131Ar2).

つまり：

  • HMAC / KMAC: 112 bits 以上の effective cryptographic strength
  • CMAC / GMAC: 128 bits 以上
  • PANのハッシュ化には単純な SHA-256 ではなく keyed hash が必須

ここで重要な注意点があります。S3の新チェックサム機能（SHA-256、SHA-512を含む）は非keyedのハッシュです。つまりカード番号を含むデータの保護にS3のチェックサム機能だけを使っても、PCI-DSS v4.0 の要件は満たしません。別途 HMAC でラップする必要があります。

これは「S3がSHA-512対応したからPCI-DSS要件を満たせる」という誤解を招きやすいので、見落とさないようにしたいところです。

HIPAA（医療情報 — 間接指定）

HIPAA は「addressable」な技術要件として暗号化を求めていますが、具体的なアルゴリズムは直接指定していません。ただしSafe Harbor（違反通知免除）を得るためにはHHSガイダンスが要求する暗号化レベルを満たす必要があり、実質的には NIST SP 800-111（暗号化 at rest）や NIST SP 800-107（承認されたハッシュの応用）に準拠することが求められます。

HIPAA は「NISTを見ろ」という構造になっているので、結局は FIPS 承認のアルゴリズム（SHA-2 / SHA-3）を選ぶことになります。

GDPR（EU — 具体指定なし）

GDPR Article 32 は “appropriate technical and organisational measures” を求めるだけで、具体的なハッシュアルゴリズムは指定していません。業界ベストプラクティス（実質 NIST 準拠）に従うという整理になります。

S3アルゴリズム × 規制マッピング

ここまでの話を、S3の10種類のアルゴリズムに重ねて整理すると以下のようになります。この表は自分がこれまで関わったコンプライアンス対応の経験と今回の調査をもとに作ったもので、AWS公式のマッピングではない点はご留意ください。

S3アルゴリズムNIST SP 800-131AFIPS 140-3PCI-DSS v4主な用途
MD5❌ 非承認❌ 非承認❌ 非承認レガシーシステム互換のみ
SHA-1⚠️ 2030年まで⚠️ 2030年まで❌ 非承認移行期の互換性。新規採用は避ける
SHA-256✅ 承認（最低推奨）✅ 承認⚠️ 単独では不十分規制下の標準選択肢
SHA-512✅ 承認（より強度）✅ 承認⚠️ 単独では不十分長期保存・高強度用途
CRC32 / CRC32C / CRC64NVMEN/AN/AN/Aエラー検知専用（暗号学的ではない）
XXHash3 / XXHash64 / XXHash128N/AN/AN/Aエラー検知専用（同上）

この表から見えてくる実務上のポイントは3つあります。

  1. MD5 は規制環境では使えない — 今回の追加はあくまでレガシー互換（既存システムとの相互運用）用であり、「MD5 をセキュリティ目的で使うため」ではないと理解しています
  2. SHA-512 の追加は FedRAMP/FIPS ユーザーに意味がある — SHA-256 だけだった選択肢に、より強度の高い選択肢が加わった点は重要です
  3. XXHash系は規制準拠には寄与しない — 暗号学的ハッシュではないので、改ざん検知や規制のハッシュ要件には該当しません。あくまで大容量データの高速なエラー検知用です

実機検証 — AWS CLI 2.34.35

ここからは自分の手元で実際に動かして確認した内容です。

検証環境

  • AWS CLI: 2.34.35（aws --version で確認）
  • リージョン: ap-northeast-1（東京）、us-east-1（N. Virginia）
  • プロファイル: your-profile
  • 対応バージョン根拠: AWS CLI CHANGELOG 2.34.35

このバージョンから aws s3api put-object の --checksum-algorithm で以下が受け付けられるようになっています。aws s3api put-object help の出力から抜粋します。

          [--checksum-algorithm <value>]
          [--checksum-crc32 <value>]
          [--checksum-crc32-c <value>]
          [--checksum-crc64-nvme <value>]
          [--checksum-sha1 <value>]
          [--checksum-sha256 <value>]
          [--checksum-sha512 <value>]
          [--checksum-md5 <value>]
          [--checksum-xxhash64 <value>]
          [--checksum-xxhash3 <value>]
          [--checksum-xxhash128 <value>]

動作確認：各アルゴリズムで S3 にアップロード

まずテスト用ファイルを用意します。

$ echo "Hello, S3 checksums! This is a test file for verifying multiple checksum algorithms." > /tmp/s3test.txt
$ wc -c /tmp/s3test.txt
      85 /tmp/s3test.txt

CRC64NVME（デフォルト）

何も指定しないとCRC64NVMEが使われます。

$ aws s3api put-object --bucket my-bucket --key crc64nvme.txt \
    --body /tmp/s3test.txt --profile your-profile
{
    "ETag": "\"6f62e62c84793726accbd84b3d595951\"",
    "ChecksumCRC64NVME": "6iq/lpaittg=",
    "ChecksumType": "FULL_OBJECT",
    "ServerSideEncryption": "AES256"
}

ChecksumType: FULL_OBJECT が付いている点に注目してください。これは「オブジェクト全体を1つの論理データとして計算したチェックサム」を意味します。後で詳しく触れます。

SHA-512（新規追加）

$ aws s3api put-object --bucket my-bucket --key sha512.txt \
    --body /tmp/s3test.txt --checksum-algorithm SHA512 --profile your-profile
{
    "ETag": "\"6f62e62c84793726accbd84b3d595951\"",
    "ChecksumSHA512": "pdo4FKlw/apCvuYQ1p1eE0tpyHp26BWN+mthlpp0NDvJta60Bzlpb79kmwLv2PAmB5EFYML+KUmWkFJkMkTn+A==",
    "ChecksumType": "FULL_OBJECT",
    "ServerSideEncryption": "AES256"
}

FIPS 140-3 / FedRAMP 環境で使える高強度の選択肢として、ここから使えるようになっています。

XXHash3 / XXHash64 / XXHash128（新規追加）

$ aws s3api put-object --bucket my-bucket --key xxhash64.txt \
    --body /tmp/s3test.txt --checksum-algorithm XXHASH64 --profile your-profile
{
    "ETag": "\"6f62e62c84793726accbd84b3d595951\"",
    "ChecksumXXHASH64": "5FwF34qZ5mc=",
    "ChecksumType": "FULL_OBJECT",
    "ServerSideEncryption": "AES256"
}

$ aws s3api put-object --bucket my-bucket --key xxhash128.txt \
    --body /tmp/s3test.txt --checksum-algorithm XXHASH128 --profile your-profile
{
    "ETag": "\"6f62e62c84793726accbd84b3d595951\"",
    "ChecksumXXHASH128": "Eb/6J3Wu0gP2G47KShnQCw==",
    "ChecksumType": "FULL_OBJECT",
    "ServerSideEncryption": "AES256"
}

XXHash 系も FULL_OBJECT タイプで正常に動きます。これは大容量データを扱う OSSツール（zstd、borg等）と相互運用したい場面で意味があります。

ハマりポイント：MD5 は --checksum-algorithm では使えない

ここが今回一番の「注意点」です。help には MD5 が列挙されていますが、--checksum-algorithm MD5 で指定するとエラーになります。

$ aws s3api put-object --bucket my-bucket --key md5.txt \
    --body /tmp/s3test.txt --checksum-algorithm MD5 --profile your-profile
aws: [ERROR]: Unsupported checksum algorithm: md5

MD5 を使う場合は、自分で MD5 値を計算して --checksum-md5 に渡す必要があります。

$ MD5_BASE64=$(openssl md5 -binary /tmp/s3test.txt | base64)
$ echo "MD5 base64: $MD5_BASE64"
MD5 base64: b2LmLIR5Nyasy9hLPVlZUQ==

$ aws s3api put-object --bucket my-bucket --key md5-direct.txt \
    --body /tmp/s3test.txt --checksum-md5 "$MD5_BASE64" --profile your-profile
{
    "ETag": "\"6f62e62c84793726accbd84b3d595951\"",
    "ChecksumMD5": "b2LmLIR5Nyasy9hLPVlZUQ==",
    "ChecksumType": "FULL_OBJECT",
    "ServerSideEncryption": "AES256"
}

これは設計上、MD5 は SDK が自動計算する対象外として扱われていることを示します。「既存システムで計算した MD5 値を S3 に運ぶ」ユースケースが想定されていて、新規に MD5 を採用することは想定していない、という意図だと自分は理解しています。これはセキュリティ設計として妥当な判断だと思います。

end-to-end 整合性の確認

実機検証で一番面白かったのは、ローカルで計算した値と S3 側が保存する値が完全に一致する点です。

$ echo "=== Local ==="
$ openssl sha256 -binary /tmp/s3test.txt | base64
/CrrFiYWoUpPvB3O11CQFDQ5kJrAsedVG558JUH3VO0=
$ openssl sha512 -binary /tmp/s3test.txt | base64
pdo4FKlw/apCvuYQ1p1eE0tpyHp26BWN+mthlpp0NDvJta60Bzlpb79kmwLv2PAmB5EFYML+KUmWkFJkMkTn+A==

$ echo "=== S3 ==="
$ aws s3api head-object --bucket my-bucket --key sha256.txt \
    --checksum-mode ENABLED --profile your-profile | grep ChecksumSHA256
    "ChecksumSHA256": "/CrrFiYWoUpPvB3O11CQFDQ5kJrAsedVG558JUH3VO0=",
$ aws s3api head-object --bucket my-bucket --key sha512.txt \
    --checksum-mode ENABLED --profile your-profile | grep ChecksumSHA512
    "ChecksumSHA512": "pdo4FKlw/apCvuYQ1p1eE0tpyHp26BWN+mthlpp0NDvJta60Bzlpb79kmwLv2PAmB5EFYML+KUmWkFJkMkTn+A==",

ローカルと S3 が完全に同じ値を持つので、10年後にローカルの元ファイルがあれば、S3側の保存値を改ざん検知のエビデンスとして使えます。これは ChecksumType: FULL_OBJECT のおかげで、マルチパートアップロードでも値が一致します。

高レベルコマンド aws s3 cp でも使える

CHANGELOGに記載の通り、高レベルの aws s3 cp でも新アルゴリズムが使えます。

$ aws s3 cp /tmp/s3test.txt s3://my-bucket/high-level-sha512.txt \
    --checksum-algorithm SHA512 --profile your-profile
upload: /tmp/s3test.txt to s3://my-bucket/high-level-sha512.txt

$ aws s3 cp /tmp/s3test.txt s3://my-bucket/high-level-xxhash64.txt \
    --checksum-algorithm XXHASH64 --profile your-profile
upload: /tmp/s3test.txt to s3://my-bucket/high-level-xxhash64.txt

sync や cp のような日常的に使うコマンドから新アルゴリズムが指定できるので、CI/CDパイプラインに組み込むハードルは低そうです。

選び方のガイドライン

公式のアルゴリズム選択ガイドは存在しないので、ここから先は自分がこれまでの経験と今回の調査をもとに整理した推奨です。あくまで考え方の一例として参考にしてください。

要件から選ぶ

  1. 特に要件がない・一般的な用途 → CRC64NVME（デフォルト）
    • AWS のデフォルトのまま。NVMe SSDのハードウェア実装があるので高速
  2. FedRAMP / FISMA / DoD 環境 → SHA-256 / SHA-512
    • FIPS 140-3 承認の暗号学的ハッシュ必須
    • 長期保存や特に強度が要る場合は SHA-512
  3. PCI-DSS v4 環境（PAN含む） → S3チェックサム + HMAC の組み合わせ
    • S3の非keyedチェックサムだけでは不十分
    • 別途 HMAC-SHA256 等でラップ
  4. 既存システムが特定のハッシュを使っている → 同じアルゴリズムで揃える
    • 既存が MD5 なら MD5（--checksum-md5 に事前計算値を渡す）
    • 既存が XXHash 系なら XXHash 系で揃える
  5. PB級データセットの高速整合性検証 → XXHash3 / XXHash128
    • 暗号学的保証は不要だが、ビット化け検知は欲しい場面
    • CRC64NVMEでも良いが、OSSツールとの互換性なら XXHash

避けるべき選択

  • 新規設計で MD5 を採用 → 基本NG。レガシー互換以外の用途で使わない
  • SHA-1 を新規採用 → 2030年の FIPS 140 historical list 入りを見据えると新規採用は推奨しない
  • PCI-DSS で S3 のチェックサムだけで PAN を保護 → keyed hash 要件を満たさない

まとめ

今回のアップデートを3行で整理すると以下のようになります。

  • 5つの新アルゴリズム追加で、S3のチェックサムは10種類体制に
  • SHA-512 / XXHash3/64/128 は high-level コマンド（aws s3 cp）でも使える
  • MD5 は --checksum-algorithm では不可、--checksum-md5 で事前計算値を渡す設計

注意点として、「S3 が SHA-512 対応したから FIPS/PCI-DSS 準拠できる」と短絡的に判断しないほうが良いと思います。特にPCI-DSS v4 は keyed hash 要件があるので、S3 の新チェックサム機能だけでは要件を満たしません。ここは自分も実装レビューで何度か見落としを見たことがあるので、強調しておきたいポイントです。

また、NIST Policy on Hash Functions により SHA-1 は2030年12月31日以降 historical list 入りします（2022年12月15日アナウンス NIST Policy on Hash Functions）。長期保存系のアーキテクチャを設計している人は、このタイムラインを意識しておきたいところです。

公式にユースケース別のアルゴリズム選択ガイドが存在しないのは、AWS が「選択は顧客の要件次第」というスタンスを取っているためだと推測しています。これは設計思想として合理的ですが、自分のように規制要件を見ている立場からすると、アルゴリズムの選択は規制要件から逆引きするのが一番確実だと感じています。

今回の 5 アルゴリズム追加は、そうした要件多様性に対応するための棚揃えだと理解すると、腹落ちしやすいかと思います。