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 の調達から廃棄までのライフサイクル管理が不要になるため、決済システムのクラウド移行における最大の障壁が取り除かれる。料金は API 呼び出し単位の従量課金で、アクティブキー 1 つあたり月額 1.00 USD、暗号化操作は 10,000 回あたり 1.00 USD から利用できる。
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 がメモリ上に露出するリスクがない。1 回の API 呼び出しのレイテンシは通常 50 ミリ秒以下であり、リアルタイム決済の要件を十分に満たす。
DUKPT キー管理が端末セキュリティを支える理由
DUKPT (Derived Unique Key Per Transaction) は、決済端末ごとにトランザクション単位で一意の暗号鍵を導出する鍵管理方式である。端末には BDK (Base Derivation Key) から派生した初期鍵 (IPEK) のみが注入され、BDK 自体は端末に保存されない。各トランザクションで IPEK からさらに派生鍵が生成されるため、仮に 1 つの鍵が漏洩しても過去・未来のトランザクションには影響しない。Payment Cryptography は DUKPT の鍵導出を HSM 内部で完結させる。CreateKey API で BDK を生成し、DeriveKey API で端末ごとの IPEK を導出する。3DES ベースの DUKPT に加え、AES-256 ベースの DUKPT (ANSI X9.24-3) もサポートしており、移行期の並行運用が可能である。BDK 1 つから最大約 100 万個の派生鍵を生成でき、大規模な端末ネットワークにも対応する。Azure Payment HSM では DUKPT の鍵導出をアプリケーション側で実装する必要があり、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 などを選択でき、決済ネットワーク側の要件に合わせて使い分ける。FPE (Format Preserving Encryption) を使えば、16 桁の PAN を同じ 16 桁の数字列に暗号化できるため、既存のデータベーススキーマを変更せずにトークナイゼーションを導入できる。PCI DSS の準拠範囲を縮小する効果は大きく、監査対象のシステムコンポーネントを大幅に削減できる。
CloudHSM との使い分け - 汎用暗号化と決済特化の境界線
AWS には CloudHSM と Payment Cryptography という 2 つの HSM サービスが存在する。CloudHSM は FIPS 140-2 Level 3 認証を取得した汎用 HSM で、PKCS#11、JCE、OpenSSL といった標準インターフェースを通じて任意の暗号化操作を実行できる。一方、Payment Cryptography は PCI PTS HSM 認証を取得した決済専用 HSM で、PIN ブロック操作、DUKPT 鍵導出、MAC 計算など決済固有の API を提供する。選択基準は明確で、カード暗号化や PIN 検証が主目的なら Payment Cryptography、TLS 終端やコード署名など汎用暗号化が目的なら CloudHSM を選ぶ。コスト面でも差がある。CloudHSM はクラスターあたり時間課金で最小構成でも月額約 1,500 USD が発生するが、Payment Cryptography は完全従量課金で月間 100 万回の操作でも約 100 USD に収まる。決済処理量が少ない事業者にとってはコスト優位性が際立つ。両サービスを併用し、決済暗号化と汎用暗号化で役割を分離する構成も実用的である。
Payment Cryptography を本番導入する際の設計指針
本番導入では、まず鍵のインポート戦略を決定する。既存オンプレミス HSM からの移行には TR-34 プロトコルが推奨される。TR-34 は RSA ベースの非対称鍵交換方式で、鍵の平文が露出しない安全な移行を実現する。ImportKey API が TR-34 をネイティブにサポートしている。可用性の面では、サービスはリージョン内で自動冗長化されるが、マルチリージョン構成では各リージョンに鍵を個別にインポートし、アプリケーション層でフェイルオーバーを制御する。監査面では全 API 呼び出しが CloudTrail に記録され、PCI DSS 要件 10 への対応が容易である。移行は段階的に進めるのが現実的で、テスト環境で PIN ブロック変換や MAC 検証の精度を確認し、並行稼働を経て本番に切り替える流れが堅実である。関連書籍 (Amazon) も参考になる。