暗号依存関係の監査と選定

選択する暗号ライブラリは、プロジェクトにおける最も重大なセキュリティ上の意思決定の一つです。善意の開発者であっても、品質の低いライブラリを使えば安全でないシステムを作ってしまう可能性があります。一方、適切に設計されたライブラリを使えば、致命的なミスを犯しにくくなります。選定プロセスでは、セキュリティ実績、API設計、保守状況、目的への適合性を評価し、体系的に判断する必要があります。

暗号ライブラリについて最初に確認すべきことの一つは、最後に独立監査を受けた時期と、その監査の対象範囲です。5年前にバージョン1.0を対象として実施された監査では、現在使用しているバージョン3.0について十分な保証を得られません。NCC Group、Trail of Bits、Quarkslab、Cure53など、信頼できるセキュリティ企業が実施し、利用予定の具体的な機能を対象としている監査を探してください。監査報告書を一般公開しているライブラリもありますが、監査実績がまったくないことは重大なリスク要因です。

NVD（National Vulnerability Database）で、そのライブラリのCVEの履歴を確認してください。確認する項目は、CVEの件数、深刻度の評価、どのような種類の脆弱性か（ロジックエラー、メモリ破壊、アルゴリズムの弱点など）、そしてメンテナーがどれほど迅速にパッチをリリースしたかです。CVEが時折発生していても迅速に修正されているライブラリは、対応力のある保守体制を示しています。深刻度の高いCVEが多数あるライブラリや、パッチ対応が遅いライブラリは危険信号です。

保守されていない暗号ライブラリは危険です。最終コミットの日付、リリース頻度、セキュリティアドバイザリに対応しているかどうかを確認してください。最終コミットから3年経過しているライブラリには、修正されることのない既知の脆弱性が存在する可能性があります。レビューの広がりという点ではコミュニティの規模も重要です。広く使われているライブラリは、ニッチなプロジェクトよりもセキュリティ研究者から詳しく検証されます。

小さく、設計上の選択肢を絞ったAPIのほうがセキュリティに適しています。アルゴリズムの選択肢や設定項目を多数公開しているライブラリでは、設定を誤る機会が増えます。用途ごとに一つの関数を提供しアルゴリズムを固定しているlibsodiumと、暗号方式、モード、鍵サイズ、パディング、IVの扱いを個別に選択するOpenSSL EVPを比較してみてください。ライブラリを誤って使いにくいほど、セキュリティを重視するプロジェクトに適しています。

秘密データを扱う操作（鍵の比較、復号、署名検証）では、秘密値に基づいて分岐したりメモリにアクセスしたりしない、定数時間のアルゴリズムを実装する必要があります。ライブラリのドキュメントに、機密性の高い操作について定数時間が保証されることが明記されているか、ソースコードで承認済みの定数時間比較関数が使われていることを確認してください。この保証がないライブラリは、タイミングサイドチャネル攻撃に対して脆弱です。

優れた暗号ライブラリは、最新のアルゴリズムをサポートし、古いアルゴリズムを非推奨にする計画を持っているべきです。暗号化にはChaCha20-Poly1305またはAES-256-GCM、署名にはEd25519またはECDSA P-256、鍵交換にはX25519、パスワードのハッシュ化にはArgon2idを提供することが望まれます。レガシーアルゴリズム（DES、RC4、MD5、SHA-1）しか提供しないライブラリは、その他の品質にかかわらず、新規導入には適していません。

推移的依存関係を評価してください。つまり、使用する暗号ライブラリがどのライブラリに依存していて、それらのセキュリティ状況がどうなっているかを確認します。libsodiumのように外部依存関係がないライブラリは、サプライチェーンリスクを最小限に抑えられます。数十個のnpmパッケージに依存し、さらに各パッケージが独自の依存関係を持つライブラリでは、サプライチェーンによる攻撃対象領域が広くなります。再現可能ビルドを使用しているかどうかも確認し、配布されたバイナリがソースコードと一致することを検証できるようにしてください。

規制対象の業界（医療、金融、政府）では、FIPS 140-2または140-3の検証済み暗号モジュールが必要になることがよくあります。FIPS検証には費用と時間がかかるため、検証済みのライブラリは一部に限られます。FIPSプロバイダーを備えたOpenSSL、Goのcrypto/tlsで使用されるBoringCrypto、一部のHSMライブラリはFIPS検証済みです。導入環境でFIPS準拠が必要な場合、この要件によって選択できるライブラリは大幅に絞られます。

ハードウェアセキュリティモジュール（HSM）やクラウドKMSサービスには、鍵操作用の独自APIがあることがよくあります。アプリケーションをAWS KMSや特定のHSMベンダーに密結合すると、ロックインのリスクが生じます。プロバイダーを切り替えられる抽象化レイヤー（TinkのKMS統合など）がライブラリに用意されているか評価してください。また、HSMベンダーがサポートを終了したり料金を引き上げたりした場合、移行コストが大きくなる可能性も考慮してください。

暗号ライブラリの依存関係を選定するうえで最も重要な原則は、確立された標準を実装する、広く知られた実績のあるライブラリを使用し、暗号プリミティブを自分で実装しないことです。理論をどれほどよく理解していても、本番コードでAES、RSA、楕円曲線演算、認証付き暗号化を正しく実装するのは非常に困難です。実績のあるライブラリを使う場合と比べて、そのリスクを負う価値があることはほとんどありません。

ライブラリ選定のチェックリスト：最近実施された独立監査の対象範囲と報告書を確認し、CVEの履歴とパッチ対応時間を調べ、積極的な保守とコミュニティの関与を確認し、誤用に強い小規模なAPIを優先し、機密性の高い操作で定数時間が保証されることを確認し、最新のアルゴリズムがサポートされていることを確認し、サプライチェーンの依存関係を評価し、規制対象であればFIPS検証を確認し、KMSのベンダーロックインリスクを考慮し、暗号プリミティブを実装するのではなく、常に実績のあるライブラリを使用してください。