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