V6: 暗号化
管理目標
V6 の目標は、暗号の一般的な使用に関するベストプラクティスを定義するだけでなく、暗号の原則に関する基本的な理解を浸透させ、より耐性があり現代的なアプローチへの転換を促すことでもあります。以下のことを推奨します。
安全に失敗し、進化する脅威に適応し、将来においても有効な堅牢な暗号システムを実装すること。
安全で業界のベストプラクティスに準拠した暗号メカニズムを利用すること。
適切なアクセス制御と監査を備えた安全な暗号鍵管理システムを維持すること。
暗号状況を定期的に評価して、新しいリスクを評価し、それに応じてアルゴリズムを適応すること。
アプリケーションのライフサイクル全体を通して暗号ユースケースを検出して管理し、すべての暗号資産が把握されて保護されていることを確保すること。
一般的な原則とベストプラクティスの概説に加えて、このドキュメントでは 付録 V の要件に関するより詳細な技術情報も提供します。
シークレット管理や通信セキュリティなど、別の問題を解決するために暗号を使用する要件は、標準の別の部分にあります。
V1.6 暗号インベントリとドキュメント
アプリケーションは分類に従ってデータ資産を保護するために、強力な暗号化アーキテクチャで設計する必要があります。すべてを暗号化することは無駄であり、なにも暗号化しないことは法的な過失となります。通常、アーキテクチャ設計や高レベル設計、デザインスプリントやアーキテクチャスパイクの際に、バランスをとる必要があります。暗号を自ら設計したり追加導入したりすることは、最初から単純に組み込むよりも、セキュアに実装するために必然的により多くのコストがかかります。
アーキテクチャ要件はコードベース全体に内在するため、単体テストや統合テストは困難です。アーキテクチャ要件はコーディングフェーズを通じてコーディング標準を考慮する必要があり、セキュリティアーキテクチャ、ピアレビューやコードレビュー、振り返りの際にレビューする必要があります。
また、アルゴリズム、鍵、証明書などの暗号資産を定期的に発見し、インベントリ化し、評価することも重要です。レベル 3 では、これにはアプリケーションでの暗号の使用を発見するための静的スキャンおよび動的スキャンの使用を含むべきです。SAST や DAST などのツールがこれに役立つかもしれませんが、より包括的なカバレッジを得るには専用のツールが必要になるかもしれません。フリーウェアのツールの例には以下のものがあります。
1.6.1
暗号鍵の管理に関する明示的なポリシーがあり、暗号鍵のライフサイクルが NIST SP 800-57 などの鍵管理標準に従っている。
2
v5.0.be-1.6.1
1.6.4
[修正] 暗号インベントリは、実行され、維持され、定期的に更新され、アプリケーションで使用されるすべての暗号鍵、アルゴリズム、証明書を含む。また、システム内で鍵を使用できる場所とできない場所、および鍵を使用して保護できるデータと保護できないデータの種類も文書化する必要がある。
2
v5.0.be-1.6.4
1.6.5
[追加] 暗号検出メカニズムが採用され、暗号化、ハッシュ化、署名操作など、システム内のすべての暗号インスタンスを識別している。
3
v5.0.be-1.6.5
V6.2 安全な暗号の実装
このセクションではアプリケーションの中核となる暗号アルゴリズムの選択、実装、および継続的な管理の要件を定義します。その目的は、現行の標準 (NIST, ISO/IEC など) やベストプラクティスに沿って、堅牢で業界で認められている暗号プリミティブのみが導入されるようにすることです。組織は各暗号コンポーネントがピアレビューされた証跡と実際のセキュリティテストに基づいて選択されるようにしなければなりません。
6.2.2
[修正, 6.5.1, 6.5.2, 6.5.4, 6.6.1, 6.7.2 へ分割] 暗号操作には業界で検証済みの実装 (ライブラリやハードウェアアクセラレーション実装を含む) が使用される。
2
v5.0.be-6.2.2
6.2.4
[修正, 1.6.3 からマージ] アプリケーションは、乱数、認証された暗号化、MAC、ハッシュアルゴリズム、鍵長、ラウンド、暗号やモードをいつでも再構成、アップグレード、または交換できるように、暗号の敏捷性を考慮して設計され、暗号解読から保護している。同様に、鍵とパスワードを置換してデータを再暗号化することも可能でなければならない。これにより、承認されたポスト量子暗号 (PQC) スキームや標準の高保証実装が広く利用可能になると、PQC へのシームレスなアップグレードが可能になる。
2
v5.0.be-6.2.4
6.2.9
[追加] すべての暗号プリミティブは、アルゴリズム、鍵サイズ、構成に基づいて、最低でも 128 ビットのセキュリティを利用している。たとえば、256 ビットの ECC 鍵はおよそ 128 ビットのセキュリティを提供するが、RSA では 128 ビットのセキュリティを実現するために 3072 ビットの鍵を必要とする。
2
v5.0.be-6.2.9
6.2.8
情報の漏洩を防ぐために、比較、計算、リターンの際に「短絡」操作がなく、すべての暗号化操作は一定時間となっている。
3
v5.0.be-6.2.8
6.2.1
[修正] すべての暗号化モジュールが安全に失敗し、パディングオラクル攻撃などの脆弱性を有効にしない方法でエラーが処理される。
3
v5.0.be-6.2.1
V6.5 暗号化アルゴリズム
AES や CHACHA20 に基づいて構築された、認証された暗号アルゴリズムは現代の暗号プラクティスのバックボーンを形成します。
6.5.1
[追加, 6.2.2, 6.2.5 から分割, 6.2.3 をカバー] 安全でないブロックモード (ECB など) や脆弱なパディングスキーム (PKCS#1 v1.5 など) を使用していない。
1
v5.0.be-6.5.1
6.5.2
[追加, 6.2.2, 6.2.5 から分割, 6.2.3 をカバー, レベル L2 > L1] AES with GCM などの安全な認証された暗号とモードのみを使用している。
1
v5.0.be-6.5.2
6.5.4
[修正, 6.2.2 から分割, 6.2.7 から移動] 暗号化されたデータは、できれば承認された認証済みの暗号方式を使用するか、承認された暗号方式と承認された MAC アルゴリズムを組み合わせることによって、認可されていない改変から保護している。
2
v5.0.be-6.5.4
6.5.3
[修正, 6.2.6 から移動, レベル L2 > L3] ナンス、初期化ベクトル、その他の使い捨て番号は複数の暗号鍵とデータ要素のペアに使用していない。生成手法は、使用されるアルゴリズムに適したものでなければならない。
3
v5.0.be-6.5.3
6.5.5
[追加] 暗号アルゴリズムと MAC アルゴリズムの組み合わせは encrypt-then-MAC モードで動作している。
3
v5.0.be-6.5.5
V6.6 ハッシュ化とハッシュベース関数
暗号ハッシュは、デジタル署名、HMAC、鍵導出関数 (KDF)、ランダムビット生成、パスワードストレージなど、さまざまな暗号プロトコルで使用されます。暗号システムのセキュリティは、使用される基盤となるハッシュ関数の強度によって決まります。このセクションでは暗号操作で安全なハッシュ関数を使用するための要件を概説します。
パスワードの保存については、暗号化の付録と同様に、OWASP Password Storage Cheatsheet も役に立つコンテキストとガイダンスを提供します。
6.6.1
[追加, 6.2.2, 6.2.5 から分割, 6.2.3 をカバー] デジタル署名、HMAC、KDF、ランダムビット生成など、一般的な暗号ユースケースには、承認されたハッシュ関数のみが使用されている。MD5 などの許可されていないハッシュ関数はいかなる暗号目的にも使用してはならない。
1
v5.0.be-6.6.1
6.6.2
[修正, 2.4.1 から移動, 2.4.3, 2.4.4 からマージ, 2.5.3 をカバー] パスワードは、現在のガイダンスに基づいて設定されたパラメータを用いた、承認された計算集約型のハッシュアルゴリズムを使用して保存されている。この設定は、セキュリティとパフォーマンスのバランスをとり、ブルートフォース攻撃をより困難にすべきである。
2
v5.0.be-6.6.2
6.6.3
[追加] データ認証やデータ完全性の一部としてデジタル署名に使用されるハッシュ関数は衝突耐性があり、適切なビット長を有している。衝突耐性が必要な場合、出力長は少なくとも 256 ビットでなければならない。第二原像攻撃攻撃への耐性のみが必要な場合、出力長は少なくとも 128 ビットでなければならない。
2
v5.0.be-6.6.3
V6.3 乱数値
暗号論的に安全な疑似乱数生成 (Cryptographically Secure Pseudo-random Number Generation, CSPRNG) を正しく行うことは非常に困難です。一般的にシステム内の優れたエントロピーソースは使い過ぎるとすぐに枯渇してしまいますが、ランダム性の少ないソースは鍵やシークレットが予測可能となる可能性があります。
6.3.1
[文法, 6.3.2 をカバー, レベル L2 > L1] 推測不可能であることを意図したすべての乱数と文字列は、暗号論的に安全な疑似乱数生成器 (CSPRNG) を使用して生成され、少なくとも 128 ビットのエントロピーを持たなければならない。UUID はこの条件を満たさないことに注意する。
2
v5.0.be-6.3.1
6.3.3
[文法, レベル L3 > L1] システム負荷の高い場合や、システムが適切にデグレードした場合でも、乱数生成は安全に機能し続ける。
3
v5.0.be-6.3.3
V6.7 公開鍵暗号
公開鍵暗号は複数の当事者間で秘密鍵を共有することが不可能または望ましくない場合に使用されます。
その一環として、暗号システムが現代の脅威に対して安全であり続けることを確保するには、Diffie-Hellman and Elliptic Curve Diffie-Hellman (ECDH) などの承認された鍵交換メカニズムが必要です。
6.7.2
[修正, 2.9.3 から移動, 6.2.2 から分割] 鍵の生成とシード、およびデジタル署名の生成と検証には、承認済みの暗号アルゴリズムと動作モードのみが使用される。
2
v5.0.be-6.7.2
6.7.1
[追加] 業界で実績のある暗号アルゴリズム (Diffie-Hellman など) を鍵交換に使用し、鍵交換メカニズムが安全なパラメータを使用することに重点を置いている。これにより、Adversary-in-the-Middle 攻撃や暗号解読につながる可能性のある鍵確立プロセスへの攻撃を防ぐことができる。
3
v5.0.be-6.7.1
V6.8 使用中のデータの暗号化
処理中のデータを保護することが最も重要です。フルメモリ暗号化、転送中の暗号化、使用後のデータの可能な限り迅速な暗号化などの技法が推奨されます。
6.8.1
[追加] フルメモリ暗号化を使用して、使用中の機密データを保護し、認可されていないユーザやプロセスによるアクセスを防いでいる。
3
v5.0.be-6.8.1
6.8.2
[追加] データの最小化により、処理中に露出するデータの量を最小限に抑え、使用後すぐに、または可能な限り速やかにデータが暗号化されることを確保している。
3
v5.0.be-6.8.2
V6.9 ポスト量子暗号 (Post-Quantum Cryptography, PQC)
量子コンピューティングの最終的な台頭に備えて、将来を見据えた暗号システムの必要性が極めて重要です。ポスト量子暗号 (Post-Quantum Cryptography, PQC) は、RSA や ECC などの現行の暗号方式を破る可能性のある量子攻撃に耐性のある暗号システムの開発に焦点を当てています。利用可能な PQC プリミティブの最新情報については付録を参照してください。
6.9.1
[追加] 暗号インベントリが維持され、現行の暗号アルゴリズムとシステムからポスト量子暗号を使用するものへの移行パスを概説する、文書化された変換計画またはマッピングを含んでいる。
3
v5.0.be-6.9.1
6.9.2
[追加] アプリケーションが新たな業界標準に準拠し、量子脅威に備えることを確保するために、ポスト量子暗号の分野の発展を監視している。
3
v5.0.be-6.9.2
参考情報
詳しくは以下の情報を参照してください。
Last updated
Was this helpful?