Skip to content

Latest commit

 

History

History
135 lines (94 loc) · 14.9 KB

0x14-V6-Cryptography.md

File metadata and controls

135 lines (94 loc) · 14.9 KB

V6 暗号化

管理目標

V6 の目標は、暗号の一般的な使用に関するベストプラクティスを定義するだけでなく、暗号の原則に関する基本的な理解を浸透させ、より耐性があり現代的なアプローチへの転換を促すことでもあります。以下のことを推奨します。

  • 安全に失敗し、進化する脅威に適応し、将来においても有効な堅牢な暗号システムを実装すること。
  • 安全で業界のベストプラクティスに準拠した暗号メカニズムを利用すること。
  • 適切なアクセス制御と監査を備えた安全な暗号鍵管理システムを維持すること。
  • 暗号状況を定期的に評価して、新しいリスクを評価し、それに応じてアルゴリズムを適応すること。
  • アプリケーションのライフサイクル全体を通して暗号ユースケースを検出して管理し、すべての暗号資産が把握されて保護されていることを確保すること。

一般的な原則とベストプラクティスの概説に加えて、このドキュメントでは 付録 V の要件に関するより詳細な技術情報も提供します。

シークレット管理や通信セキュリティなど、別の問題を解決するために暗号を使用する要件は、標準の別の部分にあります。

V1.6 暗号インベントリとドキュメント

アプリケーションは分類に従ってデータ資産を保護するために、強力な暗号化アーキテクチャで設計する必要があります。すべてを暗号化することは無駄であり、なにも暗号化しないことは法的な過失となります。通常、アーキテクチャ設計や高レベル設計、デザインスプリントやアーキテクチャスパイクの際に、バランスをとる必要があります。暗号を自ら設計したり追加導入したりすることは、最初から単純に組み込むよりも、セキュアに実装するために必然的により多くのコストがかかります。

アーキテクチャ要件はコードベース全体に内在するため、単体テストや統合テストは困難です。アーキテクチャ要件はコーディングフェーズを通じてコーディング標準を考慮する必要があり、セキュリティアーキテクチャ、ピアレビューやコードレビュー、振り返りの際にレビューする必要があります。

また、アルゴリズム、鍵、証明書などの暗号資産を定期的に発見し、インベントリ化し、評価することも重要です。レベル 3 では、これにはアプリケーションでの暗号の使用を発見するための静的スキャンおよび動的スキャンの使用を含むべきです。SAST や DAST などのツールがこれに役立つかもしれませんが、より包括的なカバレッジを得るには専用のツールが必要になるかもしれません。フリーウェアのツールの例には以下のものがあります。

# 説明 L1 L2 L3 CWE
1.6.1 暗号鍵の管理に関する明示的なポリシーがあり、暗号鍵のライフサイクルが NIST SP 800-57 などの鍵管理標準に従っている。 ✓ ✓ 320
1.6.2 [削除, 14.8.1 へマージ]
1.6.3 [削除, 6.2.4 へマージ]
1.6.4 [修正] 暗号インベントリは、実行され、維持され、定期的に更新され、アプリケーションで使用されるすべての暗号鍵、アルゴリズム、証明書を含む。また、システム内で鍵を使用できる場所とできない場所、および鍵を使用して保護できるデータと保護できないデータの種類も文書化する必要がある。 ✓ ✓ 320
1.6.5 [追加] 暗号検出メカニズムが採用され、暗号化、ハッシュ化、署名操作など、システム内のすべての暗号インスタンスを識別している。 ✓ 320

V6.1 データ分類

# 説明 L1 L2 L3 CWE
6.1.1 [削除, 1.8.1 へマージ]
6.1.2 [削除, 1.8.1 へマージ]
6.1.3 [削除, 1.8.1 でカバー]

V6.2 アルゴリズム

最近の暗号技術の進歩は、以前は安全だったアルゴリズムや鍵の長さが、データを保護するためにはもはや安全でも十分でもないことを意味しています。したがって、アルゴリズムを変更することは必要です。

このセクションはペネトレーションテストが難しく、ほとんどの項目で L1 が含まれていませんが、開発者はこのセクション全体を必須項目と考えてください。

# 説明 L1 L2 L3 CWE
6.2.1 [修正] すべての暗号化モジュールにおいて、処理に失敗した場合の安全対策が施されており、オラクルパディング攻撃などの脆弱性を許さない方法でエラーが処理される。 ✓ ✓ ✓ 310
6.2.2 独自実装された暗号化方式ではなく、業界で実績のある、または政府が承認した暗号化アルゴリズム、モード、およびライブラリが使用されている。 ✓ ✓ 327
6.2.3 [削除, 6.5.1, 6.5.2, 6.6.1 でカバー]
6.2.4 [修正, 1.6.3 からマージ] アプリケーションは、乱数、認証された暗号化、MAC、ハッシュアルゴリズム、鍵長、ラウンド、暗号やモードをいつでも再構成、アップグレード、または交換できるように、暗号の敏捷性を考慮して設計され、暗号解読から保護している。同様に、鍵とパスワードを置換してデータを再暗号化することも可能でなければならない。これにより、承認されたポスト量子暗号 (PQC) スキームや標準の高保証実装が広く利用可能になると、PQC へのシームレスなアップグレードが可能になる。 ✓ ✓ 320
6.2.5 [6.5.1, 6.5.2, 6.6.1 へ分割]
6.2.6 [6.5.3 へ移動]
6.2.7 [6.5.4 へ移動]
6.2.8 情報の漏洩を防ぐために、すべての暗号化操作が、比較や計算または返戻の際にショートカット操作がなく、一定時間となっている。 ✓ 385
6.2.9 [追加] すべての暗号プリミティブは、アルゴリズム、鍵サイズ、構成に基づいて、最低でも 128 ビットのセキュリティを利用している。たとえば、256 ビットの ECC 鍵はおよそ 128 ビットのセキュリティを提供するが、RSA では 128 ビットのセキュリティを実現するために 3072 ビットの鍵を必要とする。 ✓ ✓ ✓ 311

V6.3 乱数値

暗号論的に安全な疑似乱数生成 (Cryptographically secure Pseudo-random Number Generation, CSPRNG) を正しく行うことは非常に困難です。一般的にシステム内のエントロピーの良いソースは使い過ぎるとすぐに枯渇してしまいますが、ランダム性の少ないソースは予測可能な鍵や秘密情報につながる可能性があります。

# 説明 L1 L2 L3 CWE
6.3.1 [文法, 6.3.2 をカバー, レベル L2 > L1] 推測不可能であることを意図したすべての乱数と文字列は、暗号論的にセキュアな疑似乱数生成器 (CSPRNG) を使用して生成され、少なくとも 128 ビットのエントロピーを持たなければならない。UUID はこの条件を満たさないことに注意する。 ✓ ✓ ✓ 338
6.3.2 [削除, 6.3.1 でカバー]
6.3.3 [文法, レベル L3 > L1] 乱数生成はシステム不可の高い状況でも適切に機能するか、システムが適切にデグレードする。 ✓ ✓ ✓ 338

V6.4 シークレット管理

このセクションはペネトレーションテストが難しく、ほとんどの項目で L1 が含まれていませんが、開発者はこのセクション全体を必須項目と考えてください。

# 説明 L1 L2 L3 CWE
6.4.1 [14.8.1 へ移動]
6.4.2 [14.8.2 へ移動]

V6.5 暗号化アルゴリズム

AES や CHACHA20 に基づいて構築された、認証された暗号アルゴリズムは現代の暗号プラクティスのバックボーンを形成します。

# 説明 L1 L2 L3 CWE
6.5.1 [追加, 6.2.5 から分割, 6.2.3 をカバー] 安全でないブロックモード (ECB など) や脆弱なパディングスキーム (PKCS#1 v1.5 など) を使用していない。 ✓ ✓ 326
6.5.2 [追加, 6.2.5 から分割, 6.2.3 をカバー, レベル L2 > L1] AES with GCM などの安全な認証された暗号とモードのみを使用している。 ✓ ✓ ✓ 326
6.5.3 [修正, 6.2.6 から移動, レベル L2 > L3] ナンス、初期化ベクトル、その他の使い捨て番号は複数の暗号鍵/データ要素ペアに使用していない。生成手法は、使用されるアルゴリズムに適したものでなければならない。 ✓ 326
6.5.4 [修正, 6.2.7 から移動] 暗号化されたデータは署名だけでなく、認証された暗号モードや HMAC を通じて認証され、認可されていない改変から保護している。 ✓ 326
6.5.5 [追加] 暗号アルゴリズムと MAC アルゴリズムの組み合わせは encrypt-then-MAC モードで動作している。 ✓ 326

V6.6 ハッシュ化とハッシュベース関数

暗号ハッシュは、デジタル署名、HMAC、鍵導出関数 (KDF)、ランダムビット生成、パスワードストレージなど、さまざまな暗号プロトコルで使用されます。暗号システムのセキュリティは、使用される基盤となるハッシュ関数の強度によって決まります。このセクションでは暗号操作で安全なハッシュ関数を使用するための要件を概説します。

# 説明 L1 L2 L3 CWE
6.6.1 [追加, 6.2.5 から分割, 6.2.3 をカバー] デジタル署名、HMAC、KDF、ランダムビット生成など、一般的な暗号ユースケースには、承認されたハッシュ関数のみが使用されている。MD5 などの許可されていないハッシュ関数はいかなる暗号目的にも使用してはならない。 ✓ ✓
6.6.2 [修正, 2.4.1 から移動, 2.4.3, 2.4.4 からマージ, 2.5.3 をカバー] パスワードは、現在のガイダンスに基づいて設定されたパラメータを用いた、承認された計算集約型のハッシュアルゴリズムを使用して保存されている。この設定は、セキュリティとパフォーマンスのバランスをとり、ブルートフォース攻撃をより困難にすべきである。 ✓ ✓
6.6.3 [追加] デジタル署名に使用されるハッシュ関数は衝突耐性があり、衝突やプリイメージ攻撃などの攻撃を避けるための適切なビット長を有している。 ✓ ✓ ✓

V6.7 鍵交換メカニズム

暗号システムが現代の脅威に対して安全であり続けることを確保するには、Diffie-Hellman and Elliptic Curve Diffie-Hellman (ECDH) などの承認された鍵交換メカニズムが必要です。

# 説明 L1 L2 L3 CWE
6.7.1 [追加] 業界で実績のある暗号アルゴリズム (Diffie-Hellman など) を鍵交換に使用し、鍵交換メカニズムが安全なパラメータを使用することに重点を置いている。これにより、Adversary-in-the-Middle 攻撃や暗号解読につながる可能性のある鍵確立プロセスへの攻撃を防ぐことができる。 ✓ ✓

V6.8 使用中のデータの暗号化

処理中のデータを保護することが最も重要です。フルメモリ暗号化、転送中の暗号化、使用後のデータの可能な限り迅速な暗号化などの技法が推奨されます。

# 説明 L1 L2 L3 CWE
6.8.1 [追加] フルメモリ暗号化を使用して、使用中の機密データを保護し、認可されていないユーザやプロセスによるアクセスを防いでいる。 ✓
6.8.2 [追加] データの最小化により、処理中に露出するデータの量を最小限に抑え、使用後すぐに、または可能な限り速やかにデータが暗号化されることを確保している。 ✓ ✓

V6.9 ポスト量子暗号 (Post-Quantum Cryptography, PQC)

量子コンピューティングの最終的な台頭に備えて、将来を見据えた暗号システムの必要性が極めて重要です。ポスト量子暗号 (Post-Quantum Cryptography, PQC) は、RSA や ECC などの現行の暗号方式を破る可能性のある量子攻撃に耐性のある暗号システムの開発に焦点を当てています。

# 説明 L1 L2 L3 CWE
6.9.1 [追加] 暗号インベントリが維持され、現行の暗号アルゴリズムとシステムからポスト量子暗号/量子耐性への移行パスを概説する、文書化された変換計画またはマッピングを含んでいる。 ✓ ✓
6.9.2 [追加] アプリケーションが新たな業界標準に準拠し、量子脅威に備えることを確保するために、ポスト量子暗号の分野の発展を監視している。 ✓ ✓

参考情報

詳しくは以下の情報を参照してください。