付録 C: 暗号化標準
「暗号化」の章は単にベストプラクティスを定義するだけではありません。暗号の原則に対する理解を深め、より耐性のある最新のセキュリティ手法の採用を促進することを目的としています。この付録では、「暗号化」の章で概説されている包括的な標準を保管するために、各要件に関する詳細な技術情報を提供します。
この付録ではさまざまな暗号メカニズムの承認レベルを定義します。
承認済み (Approved) (A) メカニズムはアプリケーションで使用できます。
レガシー (Legacy) メカニズム (L) はアプリケーションで使用すべきではありませんが、既存のレガシーアプリケーションやコードとの互換性のためだけに依然として使用されるかもしれません。このようなメカニズムの使用自体は現在のところ脆弱性とはみなされませんが、できるだけ早く、より安全で将来性のあるメカニズムに置き換えるべきです。
不許可 (Disallowed) メカニズム (D) は、現時点で破壊されているとみなされているか、十分なセキュリティを提供していないため、使用してはいけません。
このリストは、以下のようなさまざまな理由により、特定のアプリケーションのコンテキストにおいて上書きされる可能性があります。
暗号分野における新たな進化
規制への準拠
暗号インベントリとドキュメント
このセクションでは V11.1 暗号インベントリとドキュメントに対する追加情報を提供します。
アルゴリズム、鍵、証明書などの暗号資産を定期的に発見し、インベントリ化し、評価することが重要です。レベル 3 では、これにはアプリケーションでの暗号の使用を発見するための静的スキャンおよび動的スキャンの使用を含むべきです。SAST や DAST などのツールがこれに役立つかもしれませんが、より包括的なカバレッジを得るには専用のツールが必要になるかもしれません。フリーウェアのツールの例には以下のものがあります。
暗号パラメータの等価な強度
さまざまな暗号システムの相対的なセキュリティ強度は以下の表のとおりです (NIST SP 800-57 Part 1, p.71 より):
<= 80
2TDEA
L = 1024 N = 160
k = 1024
f = 160-223
112
3TDEA
L = 2048 N = 224
k = 2048
f = 224-255
128
AES-128
L = 3072 N = 256
k = 3072
f = 256-383
192
AES-192
L = 7680 N = 384
k = 7680
f = 384-511
256
AES-256
L = 15360 N = 512
k = 15360
f = 512+
適用例:
有限体暗号: DSA, FFDH, MQV
整数因数分解暗号: RSA
楕円曲線暗号: ECDSA, EdDSA, ECDH, MQV
注: このセクションでは量子コンピュータが存在しないことを前提としています。そのようなコンピュータが存在する場合、最後の 3 列の推定値はもはや有効ではなくなります。
乱数値
このセクションでは V11.5 乱数値に対する追加情報を提供します。
/dev/random
Linux 4.8 以降 (2016 年 10 月)、iOS、Android、その他の Linux ベースの POSIX オペレーティングシステムにもあります。RFC7539 に基づいています。
ChaCha20 ストリームを利用します。iOS SecRandomCopyBytes および Android Secure Random にあり、それぞれに正しい設定が提供されています。
A
/dev/urandom
ランダムデータを提供するための Linux カーネルの特殊ファイルです。
ハードウェアのランダム性から高性能のエントロピーソースを提供します。
A
getentropy()
OpenBSD、Linux glibc 2.25 以降、macOS 10.12 以降 で利用可能です。
シンプルで最小限の API で、カーネルのエントロピーソースから安全なランダムバイトを直接提供します。より現代的であり、古い API に関連する落とし穴を回避します。
A
HMAC-DRBG または Hash-DRBG で使用される基礎となるハッシュ関数はこの用途に対して承認されていなければなりません。
暗号アルゴリズム
このセクションでは V11.3 暗号アルゴリズムに対する追加情報を提供します。
承認済み暗号アルゴリズムを優先順に並べています。
2TDEA
D
TDEA (3DES/3DEA)
D
IDEA
D
RC4
D
Blowfish
D
ARC4
D
DES
D
AES 暗号モード
AES などのブロック暗号はさまざまな動作モードで使用できます。電子コードブック (ECB) などの多くの動作モードは安全ではないため、使用してはいけません。ガロア/カウンタモード (Galois/Counter Mode, GCM) とカウンタ暗号ブロック連鎖メッセージ認証コード (CCM) の動作モードは、認証済み暗号化を提供するため、現代のアプリケーションでは使用すべきです。
承認済みモードを優先順に並べています。
注:
すべての暗号化されたメッセージは認証されなければなりません。CBC モードを使用する場合は必ず、メッセージを検証するために、関連するハッシュ MAC アルゴリズムがなければなりません (MUST)。一般的に、これは Encrypt-Then-Hash 方式で適用されなければなりません (MUST) (ただし、TLS 1.2 では代わりに Hash-Then-Encrypt を使用します)。これが保証できない場合、CBC を使用してはいけません (MUST NOT)。MAC アルゴリズムなしでの暗号化が許される唯一のアプリケーションはディスク暗号化です。
CBC を使用する場合、パディングの検証が一定時間で行われることを保証する必要があります。
CCM-8 を使用する場合、MAC タグは 64 ビットのセキュリティしか持ちません。これは、少なくとも 128 ビットのセキュリティを必要とする要件 6.2.9 に準拠していません。
ディスク暗号化は ASVS のスコープ外と考えられます。したがって、この付録ではディスク暗号化の承認済みの方式は記載しません。この用途では、通常、認証なしの暗号化が受け入れられ、XTS、XEX、LRW モードが一般的に使用されます。
鍵ラッピング
暗号鍵ラップ (および対応する鍵アンラップ) は、追加の暗号メカニズムを使用して既存の鍵をカプセル化 (つまりラップ) し、転送中などに元の鍵が明らかに露出しないようにすることで、既存の鍵を保護する方法です。元の鍵を保護するために使用されるこの追加の鍵はラップ鍵と呼ばれます。
この操作は、信頼できないとみなされる場所で鍵を保護したい場合、あるいは信頼できないネットワーク上やアプリケーション内で機密鍵を送信したい場合に実行できます。 ただし、ラップ/アンラップ手順を実行する前に、元の鍵の性質 (アイデンティティや目的など) を理解することを真剣に検討すべきです。これは、セキュリティと、特に鍵の機能 (署名など) の監査証跡や適切な鍵の保存を含むコンプライアンスの点で、ソースとターゲットの両方のシステム/アプリケーションに影響を及ぼす可能性があります。
特に、鍵ラッピングには、NIST SP 800-38F に従い、量子脅威に対する将来を見据えた対策を考慮して、AES-256 を使用しなければなりません (MUST)。AES を使用する暗号モードは優先順に以下のとおりです:
AES-192 と AES-128 はユースケースで必要な場合に使用できます (MAY) が、その理由はエンティティの暗号インベントリに文書化されなければなりません (MUST)。
認証された暗号
ディスク暗号化を除いて、暗号化されたデータは何かしらの形で認証された暗号 (AE) スキーム、通常は関連データ付き認証暗号 (AEAD) スキームを使用して、認可されていない変更から保護されなければなりません。
アプリケーションは承認済みの AEAD スキームを使用することをお勧めします。代わりに、承認済みの暗号スキームと承認済みの MAC アルゴリズムを Encrypt-then-MAC 構造で組み合わせることもできます。
MAC-then-encrypt はレガシーアプリケーションとの互換性のために依然として許可されています。これは古い暗号スイートを使用する TLS v1.2 で使用されます。
Encrypt-then-MAC
A
MAC-then-encrypt
L
ハッシュ関数
このセクションでは V11.4 ハッシュ化とハッシュベース関数に対する追加情報を提供します。
一般的なユースケースでのハッシュ関数
以下の表は、デジタル署名などの一般的な暗号ユースケースで承認されているハッシュ関数を示しています。
承認済みハッシュ関数は強力な衝突耐性を備えており、高セキュリティのアプリケーションに適しています。
これらのアルゴリズムの中には、適切な暗号鍵管理と併用すると攻撃に対する強力な耐性を発揮するものがあるため、HMAC、KDF、RBG 機能についても追加的に承認されています。
出力が 254 ビット未満のハッシュ関数は衝突耐性が不十分であるため、デジタル署名や衝突耐性を必要とするその他の用途には使用してはいけません。その他の用途では、レガシーシステムとの互換性と検証にのみ使用できます (ONLY) が、新しい設計には使用してはいけません。
CRC (any length)
D
パスワード保存のためのハッシュ関数
安全なパスワードハッシュには、専用のハッシュ関数を使用しなければなりません。これらの低速ハッシュアルゴリズムは、パスワードクラッキングの計算難易度を上げることで、ブルートフォース攻撃や辞書攻撃を軽減します。
argon2id
t = 1: m ≥ 47104 (46 MiB), p = 1 t = 2: m ≥ 19456 (19 MiB), p = 1 t ≥ 3: m ≥ 12288 (12 MiB), p = 1
A
scrypt
p = 1: N ≥ 2^17 (128 MiB), r = 8 p = 2: N ≥ 2^16 (64 MiB), r = 8 p ≥ 3: N ≥ 2^15 (32 MiB), r = 8
A
承認済みのパスワードベースの鍵導出関数はパスワードストレージとして使用できます。
鍵導出関数 (KDF)
汎用の鍵導出関数
パスワードベースの鍵導出関数
argon2id
t = 1: m ≥ 47104 (46 MiB), p = 1 t = 2: m ≥ 19456 (19 MiB), p = 1 t ≥ 3: m ≥ 12288 (12 MiB), p = 1
A
scrypt
p = 1: N ≥ 2^17 (128 MiB), r = 8 p = 2: N ≥ 2^16 (64 MiB), r = 8 p ≥ 3: N ≥ 2^15 (32 MiB), r = 8
A
鍵交換メカニズム
このセクションでは V11.6 公開鍵暗号に対する追加情報を提供します。
KEX スキーム
すべての鍵交換スキームに対して 112 ビット以上のセキュリティ強度が確保されていなければならず (MUST)、その実装は以下の表のパラメータ選択に従わなければなりません (MUST)。
Finite Field Diffie-Hellman (FFDH)
L >= 3072 & N >= 256
Yes
A
Elliptic Curve Diffie-Hellman (ECDH)
f >= 256-383
Yes
A
Encrypted key transport with RSA-PKCS#1 v1.5
No
D
ここでのパラメータは以下のとおりです:
k は RSA 鍵の鍵サイズです。
L は有限体暗号の公開鍵 (public key) のサイズであり、N は秘密鍵 (private key) のサイズです。
f は ECC の鍵サイズの範囲です。
新しい実装では NIST SP 800-56A & B および NIST SP 800-77 に準拠していないスキームを使用してはいけません (MUST NOT)。特に IKEv1 は本番環境で使用してはいけません (MUST NOT)。
Diffie-Hellman グループ
Diffie-Hellman 鍵交換の実装には以下のグループが承認されています。セキュリティ強度は NIST SP 800-56A, Appendix D および NIST SP 800-57 Part 1 Rev.5 に記載されています。
P-224, secp224r1
A
P-256, secp256r1
A
P-384, secp384r1
A
P-521, secp521r1
A
K-233, sect233k1
A
K-283, sect283k1
A
K-409, sect409k1
A
K-571, sect571k1
A
B-233, sect233r1
A
B-283, sect283r1
A
B-409, sect409r1
A
B-571, sect571r1
A
Curve448
A
Curve25519
A
MODP-2048
A
MODP-3072
A
MODP-4096
A
MODP-6144
A
MODP-8192
A
ffdhe2048
A
ffdhe3072
A
ffdhe4096
A
ffdhe6144
A
ffdhe8192
A
メッセージ認証コード (MAC)
メッセージ認証コード (MAC) は、メッセージの完全性と真正性を検証するために使用される暗号構造です。MAC は、メッセージと共有鍵 (secret key) を入力として受け取り、固定サイズのタグ (MAC 値) を生成します。MAC は安全な通信プロトコル (TLS/SSL など) で広く使用され、パーティ間で交換されるメッセージが本物で無傷であることを確保します。
デジタル署名
署名スキームは NIST SP 800-57 Part 1 に従って承認された鍵サイズとパラメータを使用しなければなりません (MUST):
ポスト量子暗号標準
ポスト量子暗号 (PQC) 実装は FIPS-203、FIPS-204、FIPS-205 に準拠する必要があります。現時点では、これらの標準に対応した堅牢化されたコード例やリファレンス実装は多くありません。詳細については、NIST による最初の三つの最終決定されたポスト量子暗号標準に関する発表 (2024年8月) を参照してください。
提案されている mlkem768x25519 ポスト量子ハイブリッド TLS 鍵交換方式は、Firefox リリース 132 や Chrome リリース 131 などの主要なブラウザでサポートされています。暗号テスト環境や、業界や政府が承認したライブラリ内で利用可能な場合に使用できます (MAY)。
Last updated
Was this helpful?