低エントロピーデータ・カード番号ハッシュの安全境界（APAC）

心地よくない事実があります。ハッシュ化は保護と同じではありません。クレジットカード番号のSHA-256ハッシュを保存し、完全にPCI DSSに準拠しながら、実質的にはまったく保護されていないことがあり得ます。ハッシュした値がブルートフォースに耐えるだけのエントロピーを含んでいないからです。

普段は慎重なエンジニアリングチームでもここでつまずきます。ハッシュは安全に感じられるからです。ハッシュは一方向で、関数を逆算して元を復元できない、だから当然データは守られている。欠陥はハッシュにはありません。何を入力したかにあります。

実数値で見るエントロピー問題 #

16桁のカード番号はランダムではありません。構造は公開かつ固定です:

最初の4〜6桁はIssuer Identification Number(IIN)。銀行の接頭辞であり完全公開。
最後の桁はチェックサムで、1954年に発表された Luhnアルゴリズムで計算されます。秘密ではなく誤り検出です。

次にPCI DSSが一般的に許す形でPANをマスクします。最初の4〜6桁と最後の4桁を表示し、中央の6〜8桁を隠します:

4532 AAXX XXXX 1234

IINの4桁しか分からない状態で未知なのは8桁、最大1億通りの可能値です。Luhnチェックサムを適用するとそのうち10分の1しか生き残りません。実際の探索空間は1000万値です。パスワードではなく、非常に短いリストです。

1000万ハッシュのテストにどれだけかかる? #

ここからさらに悪化します。SHA-256は設計上高速です。ギガビット速度の整合性検査のために作られたものであり、秘密の保存用ではありません。現代のGPUクラッキングベンチマークは公開され再現可能です:

ハードウェア	おおよそのSHA-256スループット
RTX 4090 GPU ×1	約85億hash/秒
RTX 4090クラスタ×4	約340億hash/秒
RTX 4090クラスタ×8	約680億hash/秒

1000万回の推測÷秒間85億=およそ千分之一秒。コンシューマーGPU一枚で。GPU一台のマシンでもレインボーテーブルを使えば瞬きする間にカード番号を「アンハッシュ」できます。

結論は率直です。準拠は安全ではない。**低エントロピー項目では、SHA-2(やSHA-3)でさえ準拠していても安全ではありません。**関数は確かに単方向ですが、入力空間が小さければ些細に使い尽くせるのです。SHA-256をSHA-512やSHA-3に替えても解決しません。同じく高速だからです。

「準拠」が本当に許していること #

PCI DSSは実際にはPANをSHA-256でハッシュせよとは言っていません。要件3.5は強力な暗号学でPANを読めなくすることを求め、keyed hashと暗号化を明示的に挙げ、saltが秘密に保たれハッシュが実質的に逆算不能ならhashed and saltedインデックスも許容すると記しています。問題は、1000万値空間に対する素の無塩SHA-256が実務上、総当たりによる可逆と変わらないことです。チェックリストは通っても要件の趣旨に失敗しています。

マスキング(先頭4-6桁および/または末尾4桁の表示)は別個の統制です。オペレーターが見るものを守るのであって、保存するものではありません。両者は容易に混同され、その混同ゆえにマスク済みだが生ハッシュのPANが本番に入り込みます。

この種のデータを正しく保護する方法 #

修正法: 低エントロピー項目をパスワードと同等に敬意を持って扱うことです。数学的に同程度に弱いためです。優先順に:

そもそも保存しない。 PANをトークナイズし、実番号は別のvaultやHSMへ。値を保存しなければ総当たり対象自体がありません。
秘密のpepper付きkeyed hashing(HMAC)。 PANで索引する必要があるなら、データベース外に置いた高エントロピーキーのHMACを使用します。鍵がなければ、入力エントロピーに関わらず総当たりは計算的に非現実的です。
メモリハードなパスワードハッシング。 値それ自体で値を守るしかない場合は、 Argon2id(RFC 9106)や scryptを値ごとの無作為saltと調整済みパラメータで使用し、各推測に実際のコストをかけます。例えば64MBメモリコストのArgon2idは0.001秒の全数探索をGPUで数か月に変えます。
saltとpepperをあらゆるところに。 値ごとの無作為saltは事前計算レインボーテーブルを打ち破り、秘密に留まるpepperはオフライン攻撃を完全に打ち破ります。

OWASP Password Storage Cheat Sheetと NIST SP 800-63Bはまさにこの理由から低エントロピー秘密へのメモリハード関数を推奨しています。

flowchart TD A[PAN保存] --> B{インデックスに必要?} B -- いいえ --> C[トークナイズ / vault / HSM] B -- はい --> D{秘密鍵はある?} D -- はい --> E[HMAC + pepper] D -- いいえ --> F[Argon2id / scrypt + salt] style C stroke:#10B981,stroke-width:2px style E stroke:#10B981,stroke-width:2px style F stroke:#10B981,stroke-width:2px

カードを超えた教訓 #

これはエントロピーが限定的なすべての固定形式識別子に適用されます。国民ID番号、電話番号、生年月日、生成の貧弱なAPIキーまで。入力空間が小さければハッシュ関数の速度は敵であり、「準拠」は「安全」の同義語ではありません。

現在のPANなどの識別子保護方法が心配ですか? 気軽に簡易チェックをご相談ください。LINE(@PureSecurity)またはメール(hello@puresecurity.com)まで。

当社のAPI & アプリケーションセキュリティレビューはコードが機密値を実際どう保存・伝送しているかを検査し、チェックリスト合格のまま実データが露出している箇所を率直にお伝えします。