PBKDF2解説: あなたのVaultを守るパスワードベース鍵導出関数

TL;DR

PBKDF2（パスワードベース鍵導出関数2）は、RFC 2898で定義されたキーストレッチングアルゴリズムです。パスワードとソルトに擬似ランダム関数（通常HMAC-SHA256）を何度も適用し、導出鍵を生成します。イテレーション回数により、ブルートフォース攻撃のコストが指数関数的に増加します。OWASPは2026年時点でSHA-256に対し600,000イテレーションを推奨しています。AppVaultはPBKDF2を600,000イテレーション、インストールごとの128ビットソルト、そしてSecure Enclave鍵で出力をラップするハードウェア結合保護を採用しています。

iPhoneのロックを解除するたび、Webサイトにパスワードを入力するたび、あるいはファイルVaultを開くたび、ソフトウェアがあなたの秘密を暗号鍵に変換しています。その変換は単なるハッシュではありません。ブルートフォース攻撃を高コストにするよう慎重に設計された関数です。最も広く展開されているその関数がPBKDF2です。

PBKDF2は「パスワードベース鍵導出関数2（Password-Based Key Derivation Function 2）」の略です。RFC 2898（PKCS #5 v2.0）で定義され、20年以上にわたりNIST推奨の標準規格です。パスワード、ソルト、イテレーション回数、希望する鍵長を入力として受け取り、暗号化、認証、その他の暗号操作に使用できる導出鍵を生成します。

本記事では、PBKDF2の仕組み、直接ハッシュ化が不十分な理由、ソルトとイテレーション回数の役割、OWASP 2026推奨のSHA-256に対する600,000イテレーション、そしてPBKDF2とArgon2id、bcrypt、scryptといった最新の代替手法との比較を解説します。また、AppVaultが自社の暗号化スタックの一部としてPBKDF2をどのように使用しているかについても説明します。

直接ハッシュ化の問題点

パスワードをそのままSHA-256でハッシュ化すると、256ビットの値が得られます。その値を鍵として使用できます。問題は速度です。最新のGPUは1秒間に数十億のSHA-256ハッシュを計算できます。攻撃者は1枚のコンシューマーGPUを使って、すべての8文字小文字パスワードを数分で試行できます。

また、直接ハッシュ化には事前計算に対する防御機能が組み込まれていません。ソルトがないと、同じパスワードは常に同じハッシュを生成します。攻撃者はレインボーテーブル（事前計算済みハッシュチェーン）を構築し、ハッシュを検索して即座にパスワードを復元できます。

PBKDF2はこれら2つの問題を解決します。ハッシュを数千回繰り返すことで、各試行の計算コストを高くします。ソルトを必須とするため、同じパスワードでも異なる鍵が生成されます。イテレーション回数とソルトの組み合わせにより、高速なハッシュが低速で一意な導出に変わります。

PBKDF2の仕組み

PBKDF2は擬似ランダム関数（PRF、通常はHMAC-SHA256またはHMAC-SHA1）に基づいています。アルゴリズムは次のように動作します。

1. パスワードとソルトが結合される。
2. PRFがソルトにブロックカウンタ（鍵長がPRF出力より長い場合）を連結したものに適用される。
3. 出力が前回のイテレーションの結果とXORされる（最初のイテレーションでは前回の結果はPRF出力そのもの）。
4. 手順2〜3が指定されたイテレーション回数だけ繰り返される。
5. 最終出力が導出鍵となる。

イテレーション回数は重要なパラメータです。各イテレーションは一定量の作業を追加します。攻撃者がパスワードをテストするには、イテレーションの連鎖全体を実行する必要があります。600,000イテレーションの場合、1回のパスワード試行は単一のSHA-256ハッシュの約60万倍の時間がかかります。

ソルトはユーザーまたはインスタンスごとに一意でなければなりません。NISTは128ビットソルト（16バイト）を最小推奨としています。ソルトは導出鍵（またはVaultメタデータ）と一緒に保存され、認証時に導出を再現できるようにします。

OWASP 2026推奨

OWASPはパスワード保存チートシートを公開しており、さまざまな鍵導出関数のイテレーション回数を推奨しています。2026年時点でのPBKDF2-HMAC-SHA256の推奨は600,000イテレーションです。PBKDF2-HMAC-SHA1の場合は1,300,000イテレーションが推奨されています。これはSHA1が160ビット出力を生成し、1イテレーションあたりわずかに高速であるためです。

これらの数値は恣意的なものではありません。現代のコンシューマーハードウェアで1回のパスワード試行におよそ0.1秒かかるように調整されています。この遅延は正当なユーザーには知覚できませんが、ブルートフォース攻撃を極めて低速にします。100台のGPUクラスターを持つ攻撃者でも、1秒間に数百パスワードしか試行できず、数十億には及びません。

イテレーション回数はハードウェアの進歩に合わせて増加させるべきです。OWASPは定期的に推奨値を更新しています。AppVaultは2026年のガイドラインに合わせてPBKDF2-HMAC-SHA256に600,000イテレーションを使用しています。

イテレーション回数のトレードオフ

イテレーション回数が多いほどブルートフォース攻撃は困難になりますが、正当なデバイスでの鍵導出時間も増加します。iPhoneでは、HMAC-SHA256の600,000イテレーションに約0.2秒かかります。これはVaultのロック解除には許容範囲です。しかし、イテレーション回数を1,000万に上げると、ロック解除時間は3秒を超え、ユーザー体験を損なうでしょう。

また、消費電力のトレードオフもあります。モバイルデバイスのバッテリーには限りがあります。各イテレーションはCPUサイクルを消費します。AppVaultは、バッテリーを消耗させずユーザーをイライラさせない範囲で、強力な保護を提供するイテレーション回数を選択することで、セキュリティとユーザビリティのバランスを取っています。

もう一つのトレードオフはメモリ使用量です。PBKDF2はメモリハードではありません。イテレーション回数に関係なく、少量の固定メモリしか使用しません。そのため、多くのパスワード試行を並列化できるGPUやASIC攻撃に対して脆弱です。Argon2idやscryptのようなメモリハード関数は、1回の試行に大量のメモリを必要とするため、並列攻撃のコストがはるかに高くなります。PBKDF2は、メモリハード性の欠如を高いイテレーション回数で補い、AppVaultの場合はSecure Enclaveによるハードウェア結合でさらに強化しています。

PBKDF2 vs. Argon2id、bcrypt、scrypt

PBKDF2だけがパスワードベース鍵導出関数ではありません。他によく使われる3つの関数として、bcrypt、scrypt、Argon2idがあります。それぞれ設計目標とセキュリティ特性が異なります。

Bcryptは1999年に設計され、Blowfishベースの鍵スケジュールを使用します。固定量のメモリ（4KB）を必要とし、コストファクターが組み込まれているため、GPU攻撃に耐性があります。Bcryptは広くサポートされていますが、最大パスワード長が72バイトです。CPU上の速度がArgon2idより遅く、可変メモリ使用量に対応していないため、新しいシステムでは推奨されません。

Scryptは2009年に設計され、メモリハードです。大量のメモリ（設定可能）とCPU時間を必要とします。Scryptはメモリ帯域幅がボトルネックとなるため、ASICやGPU攻撃に耐性があります。一部の暗号通貨ウォレットやファイル暗号化ツールで使用されています。ただし、PBKDF2ほど広く実装されておらず、NIST標準もありません。

Argon2idは2015年のパスワードハッシュコンテストの勝者です。新しいシステムに最も推奨される最新のKDFです。Argon2idはメモリハード、CPUハードであり、サイドチャネル攻撃に耐性があります。Argon2d（データ依存）、Argon2i（データ非依存）、Argon2id（ハイブリッド）の3つのバリアントがあります。OWASPは新しいアプリケーションにArgon2idを推奨しています。

PBKDF2は、シンプルで標準化されており、主要な暗号ライブラリすべてで利用できるため、依然として最も広く展開されているKDFです。iOSのCommonCrypto、AndroidのKeyStore、多くのエンタープライズシステムのデフォルトです。プラットフォームの制約や互換性の要件によりArgon2idを使用できないアプリケーションにとって、高いイテレーション回数とハードウェア結合を備えたPBKDF2は強力な選択肢です。

AppVaultがPBKDF2を使用する方法

AppVaultはPBKDF2-HMAC-SHA256を600,000イテレーション、インストールごとの128ビットソルトで使用しています。ソルトは初期セットアップ時に生成され、デバイスのSecure Enclaveに保存されます。導出鍵はさらにSecure Enclave内部で生成された鍵でラップされ、その鍵はチップから外部に出ることはありません。これによりハードウェア結合保護が実現します。攻撃者がPBKDF2の出力を抽出しても、Secure Enclaveの鍵がなければ使用できません。

AppVaultのパターンロックは5×5グリッド上のパターンであり、それがパスワード文字列に変換されます。その文字列がソルトとともにPBKDF2に入力されます。得られた導出鍵は、Vaultのカタログと各ファイルを個別にAES-256-GCMで暗号化するために使用されます（ファイルごとに一意の96ビットナンス）。

AppVaultのゼロ知識アーキテクチャにより、パスワードはデバイスから外部に出ることはありません。PBKDF2の導出はすべてiPhone上で行われます。AppVaultのサーバー（存在しません）がパスワードや導出鍵を見ることは決してありません。脅威モデルでは、攻撃者がデバイスに物理的にアクセスする可能性を想定していますが、パスワードとSecure Enclave鍵がなければVaultは封印されたままです。

このカテゴリの他のVaultアプリは、異なる鍵導出アプローチを採用しています。イテレーション回数、ソルト処理、ハードウェア結合とソフトウェアのみの鍵管理といったアーキテクチャの比較は、専用の比較ページ（AppVault vs Vaultaire および AppVault vs Keepsafe）に掲載されています。AppVaultは自社の完全な暗号スタックを一次ソースの引用とともに公開しており、これが独立した検証の前提条件です。

開発者向け実践的考慮事項

PBKDF2を実装する場合は、以下のガイドラインに従ってください。

• PRFとしてHMAC-SHA256を使用してください。SHA1も使用可能ですが、より多くのイテレーションが必要です。
• ユーザーまたはインスタンスごとに少なくとも16バイトのランダムソルトを生成してください。
• イテレーション回数は現在のOWASP推奨値（2026年時点でSHA-256に対して600,000）に設定してください。
• ソルトとイテレーション回数を導出鍵（またはVaultメタデータ）と一緒に保存し、導出を再現できるようにしてください。
• デバイスが侵害された場合でも導出鍵を保護するために、ハードウェア結合（例：Secure Enclave、TPM）を検討してください。
• 認証システムでのパスワード保存にPBKDF2を使用せず、可能であればArgon2idを使用してください。PBKDF2はローカル暗号化シナリオでの鍵導出に最も適しています。

結論

PBKDF2は20年以上にわたりパスワードと暗号鍵を保護してきた実績のある鍵導出関数です。最新のKDFではありませんが、最も広くサポートされており、適切に設定すればブルートフォース攻撃に対して強力な保護を提供します。OWASP 2026のSHA-256に対する600,000イテレーション推奨により、各パスワード試行のコストは攻撃者を抑止するのに十分な高さになっています。

AppVaultはPBKDF2を600,000イテレーション、インストールごとのソルト、そしてSecure Enclaveラッピングと組み合わせてファイルを保護しています。高いイテレーション回数とハードウェア結合の組み合わせにより、ソフトウェア攻撃と物理攻撃の両方に耐性を持つVaultが実現します。パスワードリセットもバックドアもサーバーサイドの鍵復元もありません。データのセキュリティはパスワードの強度とPBKDF2導出の完全性に依存します。

AppVaultが暗号技術をどのように実装しているか詳しく知りたい場合は、暗号化概要と脅威モデルをご覧ください。