Amazon Web Services ブログ
AWS KMS と AWS Encryption SDK が対称暗号化の境界を克服する仕組み
本ブログは 2026 年 4 月 3 日に公開された AWS Blog “How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds” を翻訳したものです。
大量のデータを暗号化する大規模なアプリケーションを運用している場合、暗号化限界の追跡や鍵のローテーションが課題になることがあります。この記事では、AWS Key Management Service (AWS KMS) と AWS Encryption SDK が、派生鍵方式を用いて Galois Counter Mode の Advanced Encryption Standard (AES-GCM) の encryption limits (暗号化限界) や bounds (境界) を自動的に処理し、手動での管理を不要にする仕組みを説明します。これらの方式では、ランダムなノンスを使って、メインキー K から新しい派生鍵 Kd を生成します。これにより、暗号化のたびに一意の鍵が使われるため、K をはるかに長く使い続けられます。同様の派生鍵モードは、(KC-)XAES、DNDK v2、ia.cr/2020/1153 など、最近のさまざまなスキームでも提案されています。
対称暗号化の境界
対称暗号化アルゴリズムは、転送中のデータと保管中のデータを大量に暗号化します。最新の暗号は、認証タグを使ってデータの認証も行います。これらは追加データ付き認証暗号 (AEAD) と呼ばれます。AEAD 暗号の例としては、AES-GCM や ChaCha20/Poly1305 があります。
AES-GCM は最も広く使われている暗号化アルゴリズムで、NIST によって SP 800-38D として標準化されました。AES-GCM は、128 ビットまたは 256 ビットの鍵 K と、初期化ベクトル (IV。通常は 96 ビット) を使って、平文 P を暗号化し認証します。また、追加認証データ (AAD) も認証します。出力は暗号文 C と認証タグ T です。
(C, T) = AES-GCM(K, IV, AAD, P)
復号時には、受信者は K、IV、AAD を使って C を復号し、タグ T を検証します。タグの認証が成功すれば、元の平文 P が得られます。
暗号化呼び出し限界
データを暗号化するときには、鍵 K の使用期間中、K, IV のタプルが繰り返されないことが極めて重要です。繰り返されると、AES-GCM のセキュリティ特性が失われてしまうためです。SP 800-38D では、実装において鍵と IV が再利用される確率を 42.9 億分の 1 未満 (<2-32) にすることが求められています。これは、繰り返されない決定論的な IV を使うか、ランダムな IV を使うことで達成できます。ランダムな IV を使う場合は、232 回の暗号化後に鍵を再生成する必要があります。たとえば、TLS や IKEv2/IPsec のような一般的なプロトコルでは、接続ごとに決定論的な (つまりランダムな値から始めてインクリメントする) IV を使うことで、(K, IV) の衝突を防いでいます。
データ境界
(K, IV) の衝突確率が統計的に無視できる (<2-32) と仮定しても、同じ鍵 K で大量の平文を暗号化するときには、依然としてデータ境界が存在します。AES-GCM のブロックカウンターは 32 ビットであるため、1 回の暗号化操作 ((K, IV) のペアごと) あたり 232-2 ブロック (68.72 GB) という限界が生じます。さらに、データの総量を制限しないと、攻撃者が 2 つの異なる平文を識別できる、つまり 2 つのメッセージのうちどちらが暗号文に暗号化されているかを判別できるようになり、セキュリティ保証が低下します。識別不可能性の保護を高めるほど、暗号化できるバイト総数は少なくなります。NIST の仕様 SP 800-38D では、単一の鍵 K で保護するデータの限界を 268 バイトと示しており、これは識別不可能性の確率 50% に相当します。さまざまな分析 (ia.cr/2024/051、10.1145/3243734.3243816) に基づいて、より保守的なセキュリティマージンが使われることもあります。AWS もより保守的なマージンを設定しており、デフォルトでは無視できる程度の識別不可能性の確率 (<2-32) を強制しています。
あるセキュリティマージンにおける AES-GCM のデータ境界に達したら、対称鍵をローテーションする必要があります。こうした限界 (たとえば、ランダムな IV を使った鍵あたり 232 回の暗号化や、鍵あたりの最大データ総量) には、最新の大規模な暗号化ユースケースで到達する可能性があります。多数の同時セッションを持つ分散システム全体でこれらの限界を追跡すると、運用上の複雑さが増します。AWS では、AWS の規模で AES-GCM を使う際のこうした課題を、2023 年に開催された NIST の第 3 回 Workshop on Block Cipher Modes of Operation での 解説資料 と プレゼンテーション で共有しました。
AWS KMS が派生鍵を使う仕組み
AWS KMS は、データの暗号化と署名に使う鍵を作成し制御できるマネージドサービスです。AWS KMS Encrypt API は、対称暗号化と非対称暗号化をサポートしています。対称鍵暗号化の場合、AWS KMS は 256 ビットの鍵を使った AES-GCM を用いて、最大 4 KB のサイズの平文を暗号化します。AWS KMS リクエストには、平文と、KMS に保管されている対称カスタマーマネージドキー (CMK) の対称鍵識別子 (KeyId) が含まれます。
AWS KMS への対称鍵 Encrypt API コールでは、平文を暗号化する前に CMK を使って対称暗号化鍵を派生させます。AWS KMS は、ランダムな 128 ビットのノンス N を生成し、鍵導出関数 (KDF) を使って、KeyId で指定されたメインキー K から 256 ビットの対称鍵を生成します。KDF は、鍵、ラベルとコンテキスト、呼び出し固有のノンス N、そしてバイト単位の出力長 LKm を入力として受け取り、その長さの鍵マテリアルを Kmat = KDF(K, <label>, <context>, N, LKm) として生成します。<label> は通常、アプリケーション固有または呼び出し固有の値です。<context> には呼び出し固有の入力が含まれます。AWS KMS の場合、KDF 関数は NIST SP 800-108r1 Counter Mode KDF で、擬似ランダム関数として HMAC-SHA256 を使って 256 ビットの鍵マテリアルを生成します。Kd は基本的に、鍵 K を使った 1 回の HMAC-SHA256 呼び出しで次のように生成されます。
Kd = HMAC-SHA256(K, <ctx>)
ここで <ctx> は、カウンター値と定数および N を連結したものです。
続いて、AWS KMS は 96 ビットのランダムな IV を生成し、入力された平文 P を AES-GCM で (C, T) = AES-GCM(Kd, IV, AAD, P) として暗号化します。
AWS KMS は、IV、ノンス N、暗号文、タグ (C,T) を含む CiphertextBlob を返します。これにより、後続の Decrypt API への呼び出しで CiphertextBlob を復号できます。
直感的に言うと、CMK のもとで暗号化鍵を派生させるために使われる 128 ビットのランダムなノンスにより、呼び出し元は CMK のもとで実行できる暗号化回数の 232 限界をはるかに超えられます。さらに、AWS Encrypt 呼び出しのペイロードサイズに対する 4 KB の限界により、暗号化鍵のもとで暗号化されるデータの総量は、NIST やその他のより保守的な暗号化データ総量の上限（境界）をはるかに下回るよう保たれます。このスキームのセキュリティ基盤に関する詳細と数学的な背景については、Key Management Systems at the Cloud Scale を参照してください。
AWS Encryption SDK が呼び出しごとに派生鍵モードを適用する仕組み
AWS Encryption SDK は、データの暗号化と復号に使われるクライアント側の暗号化ライブラリです。複数のペイロードを暗号化するときに API コールを減らすため、データキーキャッシュを使うように設定できます。AES-GCM の暗号化呼び出しごとにノンスベースの派生鍵を使うことで、単一のデータキーのもとで暗号化するデータの総量を追跡する必要がなくなります。
AWS Encryption SDK は多くの暗号化シナリオに対応する柔軟性を備えていますが、デフォルト設定では鍵導出とフレームサイズの設定を自動的に処理するため、ほとんどのユースケースでこれらの設定を調整する必要はありません。AWS KMS と同様に、呼び出しごとに異なる鍵を派生させるために、ランダムに生成された値 N、メインキー K、そして KDF 内の呼び出し固有のコンテキストを使います。N はデフォルト設定では 256 ビットです。基盤となる KDF は、デフォルトのハッシュとして SHA512 を使う HMAC ベースの抽出展開鍵導出関数 (HKDF) です。Kd は基本的に、鍵 K を使った 1 回の HKDF 呼び出しで次のように生成されます。
Kd = HKDF(K, salt=<lbl>, info=<ctx>, 32)
ここで <lbl> は定数であり、<ctx> はデフォルト設定では定数とランダムな 256 ビットの値を連結したものです。
続いて、AWS Encryption SDK は派生鍵 Kd を使って、デフォルトでは 4 KB のフレームに分割されたユーザーコンテンツを暗号化します。各フレームの平文 Pf は、決定論的な IV を使った AES-GCM で (C, T) = AES-GCM(Kd, IV, AAD, Pf) として暗号化されます。
96 ビットの決定論的な IV は、フレームカウンター frameID で構成され、frameID<232 です。追加認証データ AAD は Encryption SDK のデータフレームに固有 です。復号時には、受信者は同じ方法で K から Kd を派生させ、暗号文 C を復号してフレームの平文 Pf を生成し、認証タグ T を検証します。
4 KB のフレームサイズにより、デフォルトでは単一の暗号化鍵のもとで暗号化できるデータは 244 バイト (各 4 K バイトの 232 フレーム) を超えないことが保証されます。これは、データキーキャッシュを使った場合でも、NIST が示す境界 (268) をはるかに下回ります。また、AWS の保守的な要件である <2-32 の識別不可能性の確率もはるかに下回ります。鍵あたりの呼び出し回数の限界は、データキーキャッシュを使った場合でも、ほとんどの大規模アプリケーションの暗号化回数を上回ります。
注: AWS Encryption SDK はデフォルト設定で保守的な選択をしていますが、レガシーのバージョン 1.0 を使っている場合や設定を変更している場合は、セキュリティ保証が低くなる可能性があります。たとえば、232-1 バイトというカスタムで最大化したフレームサイズを使うと、平文の合計サイズが大きくなります。これは NIST が示す限界 268 は下回りますが、その他の保守的な境界は下回りません。
なお、デフォルトの AWS Encryption SDK 設定は、鍵コミットメント のような、あまり知られていないセキュリティ特性も提供します。コミットメント文字列 は、K と HKDF を使って、派生鍵と同様に生成されます。
まとめ
暗号化呼び出しごとに一意の鍵を派生させることで、AWS KMS と AWS Encryption SDK は、AES-GCM の限界を手動で追跡する必要をなくします。
AES-GCM の境界に関する学術的な根拠については、SP 800-38D と draft-irtf-cfrg-aead-limits を参照してください。KMS で使われる鍵導出スキームの暗号解析についてさらに詳しく知りたい場合は、Key Management Systems at the Cloud Scale を参照してください。Encryption SDK の AES-GCM 鍵導出の詳細については、AWS Encryption SDK algorithms reference を参照してください。
この記事に関するご質問がある場合は、AWS Security, Identity, & Compliance re:Post で新しいスレッドを開始するか、AWS サポートにお問い合わせください。