AWS Payment Cryptography の HSM アーキテクチャ - PCI DSS 準拠の決済暗号化基盤を深掘りする
AWS Payment Cryptography は決済業界に特化したマネージド HSM サービスであり、PCI DSS 準拠の暗号化・トークナイゼーションをサーバーレスで提供する。本記事では PIN ブロック生成、DUKPT キー管理、CloudHSM との使い分けなど、決済暗号化の技術的な仕組みを掘り下げて解説する。
決済業界がマネージド HSM を必要とする背景
クレジットカード決済の暗号化処理には、PCI PTS HSM と呼ばれる物理セキュリティモジュールが不可欠である。従来、決済事業者はオンプレミスに専用 HSM を設置し、機器の調達と保守契約、設置環境の物理セキュリティ確保、監査対応までを自前で抱えてきた。これらは取引量に関係なく発生する固定費であり、負担は小さくない。HSM のファームウェア更新、鍵のローテーション、物理的なアクセス制御など、運用負荷は極めて高い。AWS Payment Cryptography はこの課題を解消するために設計されたサービスで、PCI DSS Level 1 および PCI PIN Security の要件を満たすマネージド HSM 基盤を提供する。利用者は API を呼び出すだけで、カード番号 (PAN) の暗号化、PIN ブロックの生成・検証、MAC (メッセージ認証コード) の計算といった決済固有の暗号化操作を実行できる。HSM の調達から廃棄までのライフサイクル管理が不要になるため、決済システムのクラウド移行における最大の障壁が取り除かれる。料金は (2026 年 8 月時点・バージニア北部および東京) アクティブキーの保有数と API リクエスト数に対する従量課金である。アクティブキーは 1 つあたり月額 1.00 USD で、保有数の階層に応じて 0.10 / 0.01 / 0.001 USD まで下がる。API リクエストは月間数量の逓減階層で課金され、最初の 2,000 万リクエストまでは 10,000 リクエストあたり 2.00 USD、以降は 0.75 / 0.25 / 0.10 USD と段階的に下がる (2026 年 8 月時点・API 種別による価格差はない)。両リージョンでキー単価・リクエスト単価は同額である。
PIN ブロック生成・検証の暗号学的な仕組み
ATM やカード端末で入力された PIN は、平文のまま伝送されることはない。PIN は PIN ブロックと呼ばれるフォーマットに変換され、暗号化された状態でネットワークを流れる。ISO 9564 で定義される PIN ブロックフォーマットのうち、Payment Cryptography は Format 0 (ISO-0)、Format 1 (ISO-1)、Format 3 (ISO-3)、Format 4 (ISO-4) をサポートする。Format 0 は PIN と PAN を XOR 演算で結合する方式で、最も広く普及している。一方、Format 4 は AES 暗号化を前提とした最新フォーマットで、3DES の廃止に伴い移行が進んでいる。Payment Cryptography の TranslatePinData API を使えば、異なるフォーマット間の変換をサーバーサイドで安全に実行できる。PIN の検証には VerifyPinData API を使用し、HSM 内部で復号・照合が完結するため、平文 PIN がメモリ上に露出するリスクがない。これらはいずれも同期 API として提供されるため、オーソリゼーション処理のフローにそのまま組み込める。AWS はレイテンシの目標値を公表していないため、応答時間が要件に収まるかは自環境での実測で確認するのが確実である。
DUKPT キー管理が端末セキュリティを支える理由
DUKPT (Derived Unique Key Per Transaction) は、決済端末ごとにトランザクション単位で一意の暗号鍵を導出する鍵管理方式である。端末には BDK (Base Derivation Key) から派生した初期鍵 (IPEK) のみが注入され、BDK 自体は端末に保存されない。各トランザクションで IPEK からさらに派生鍵が生成されるため、仮に 1 つの鍵が漏洩しても過去・未来のトランザクションには影響しない。Payment Cryptography は DUKPT の鍵導出を HSM 内部で完結させる。BDK は CreateKey API で生成し、端末に注入する IPEK は ExportKey API にエクスポート属性 ExportDukptInitialKey と KSN (Key Serial Number) を指定して生成・エクスポートする。DeriveKey は API 名ではなく鍵の用途属性 (KeyModesOfUse) の値で、BDK 側に DeriveKey を有効にした属性を設定しておく必要がある。エクスポートした IPEK はサービス側に永続化されず、以降の API 操作の対象にもならないため、端末への注入は取得時に完了させる設計が前提になる。3DES ベースの DUKPT に加え、AES-256 ベースの DUKPT (ANSI X9.24-3) もサポートしており、移行期の並行運用が可能である。注意したいのは「約 100 万」という数字の位置づけである。これは BDK から導出できる端末鍵の個数ではなく、KSN のトランザクションカウンタに由来する上限である。TDES DUKPT の KSN は 10 バイトで、公式ドキュメント記載の構成 (2026 年 8 月時点) では Key Set ID 24 bit・端末 ID 19 bit・トランザクションカウンタ 21 bit に分かれ、1 つの IPEK で扱えるトランザクション数がおよそ 100 万回に制限される。AES DUKPT の KSN は 12 バイトで、BDK ID 32 bit・導出識別子 32 bit・カウンタ 32 bit となりカウンタ長が大きく広がる。収容できる端末台数は KSN の識別子部分をどう設計するかで決まるため、鍵の払い出し方針は端末数と 1 台あたりの取引量の両面から検討する。Azure Payment HSM は Thales payShield 10K を単一テナントで貸与する形態で、DUKPT の鍵導出自体は payShield のホストコマンドとして利用できる。ただしコマンド列の実装と HSM の運用 (ファームウェア更新・冗長構成・キャパシティ設計) は利用者側の責任になる。マネージド API で完結する Payment Cryptography との違いは、鍵導出ができるかどうかではなく、どこまでを自前で持つかの線引きにある。
トークナイゼーションとカードデータ保護の実装パターン
PCI DSS v4.0 では、カード番号 (PAN) の保存時に暗号化またはトークナイゼーションによる保護が要求される。Payment Cryptography を使ったトークナイゼーションの典型的な実装では、PAN を EncryptData API で暗号化し、暗号文をトークンとして DynamoDB に格納する。決済処理時には DecryptData API で復号し、決済ネットワークに送信する。この方式では PAN の平文がアプリケーションサーバーのメモリに一時的に存在するため、Lambda の実行環境を活用してメモリの生存期間を最小化する設計が推奨される。暗号化アルゴリズムは AES-256-CBC、AES-256-ECB、3DES-CBC などを選択でき、決済ネットワーク側の要件に合わせて使い分ける。なお EncryptData が対応するのは対称鍵 (TDES / AES)、非対称鍵 (RSA)、DUKPT や EMV による導出鍵を用いた暗号化で、形式保存暗号 (FPE / FF1 / FF3) は含まれない。平文長も TDES は 8 バイト単位、AES は 16 バイト単位に揃える必要があるため、16 桁の PAN を同じ 16 桁の数字列として出力することはできない。桁数を保った代替値を既存スキーマに格納したい場合は、トークンと暗号文の対応を保持する仕組みを別途実装するか、専用のトークナイゼーション製品を組み合わせる必要がある。既存データベースの桁数制約が変更できない環境では、ここが移行設計の分岐点になる。PCI DSS の準拠範囲を縮小する効果は大きく、監査対象のシステムコンポーネントを大幅に削減できる。
CloudHSM との使い分け - 汎用暗号化と決済特化の境界線
AWS には CloudHSM と Payment Cryptography という 2 つの HSM サービスが存在する。CloudHSM は汎用 HSM で、PKCS#11、JCE、OpenSSL といった標準インターフェースを通じて任意の暗号化操作を実行できる。認証は HSM の世代で異なり、現行の hsm2m.medium は FIPS 140-3 Level 3 認証 (証明書 #4703) を取得しており、FIPS モードのクラスターとして構成できる。旧世代 hsm1.medium の FIPS 140-2 Level 3 認証 (証明書 #4218) は 2026 年 1 月 4 日に CMVP の historical list へ移行しており、公式ドキュメントでも hsm2m.medium への移行が推奨されている。一方、Payment Cryptography は PCI PTS HSM 認証を取得した決済専用 HSM で、PIN ブロック操作、DUKPT 鍵導出、MAC 計算など決済固有の API を提供する。選択基準は明確で、カード暗号化や PIN 検証が主目的なら Payment Cryptography、TLS 終端やコード署名など汎用暗号化が目的なら CloudHSM を選ぶ。コスト構造にも差がある。(2026 年 8 月時点・バージニア北部 / 東京) CloudHSM の課金単位はクラスターではなく HSM 1 台あたりの時間課金で、hsm2m.medium はバージニア北部で 1.60 USD/時、東京で 1.81 USD/時である。月 730 時間換算では 1 台構成で約 1,168 USD / 約 1,321 USD、可用性のために推奨される 2 台構成では約 2,336 USD / 約 2,642 USD となり、クラスターを起動している間は暗号化の実行量に関係なく発生する。対する Payment Cryptography はアクティブキー数と API リクエスト数の従量課金で、10,000 リクエストあたりの単価が 0.10 USD から 2.00 USD の階層に分かれる。月間 100 万リクエストなら全量が最初の階層に収まり約 200 USD で、数量が大きくなるほど 10,000 リクエストあたりの単価が下がる。見積りは公式料金表の数量階層で行う。決済処理量が少ない事業者にとっては、起動しているだけで積み上がる固定費が無い点が大きな優位になる。両サービスを併用し、決済暗号化と汎用暗号化で役割を分離する構成も実用的である。
Payment Cryptography を本番導入する際の設計指針
本番導入では、まず鍵のインポート戦略を決定する。既存オンプレミス HSM からの移行には TR-34 プロトコルが推奨される。TR-34 は RSA ベースの非対称鍵交換方式で、鍵の平文が露出しない安全な移行を実現する。ImportKey API が TR-34 をネイティブにサポートしている。可用性の面では、サービスはリージョン内で自動冗長化されるが、マルチリージョン構成では各リージョンに鍵を個別にインポートし、アプリケーション層でフェイルオーバーを制御する。監査面では全 API 呼び出しが CloudTrail に記録され、PCI DSS 要件 10 への対応が容易である。移行は段階的に進めるのが現実的で、テスト環境で PIN ブロック変換や MAC 検証の精度を確認し、並行稼働を経て本番に切り替える流れが堅実である。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。