V6 は単にベストプラクティスを定義するだけではありません。暗号の原則に対する理解を深め、より耐性のある最新のセキュリティ手法の採用を促進することを目的としています。この付録では、V6 で概説されている包括的な標準を保管するために、各要件に関する詳細な技術情報を提供します。
さまざまな暗号システムの相対的なセキュリティ強度は以下の表のとおりです (NIST SP 800-57 Part 1, p.71 より):
| セキュリティ強度 | 対称鍵アルゴリズム | 有限体暗号 (DSA, DH, MQV) | 整数因数分解暗号 (RSA) | 楕円曲線暗号 (ECDSA, EdDSA, DH, MQV) |
|---|---|---|---|---|
| <= 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+ |
注: このセクションでは量子コンピュータが存在しないことを前提としています。そのようなコンピュータが存在する場合、最後の 3 列の推定値はもはや有効ではなくなります。
| 名称 | バージョン/リファレンス | 備考 | L1 | L2 | L3 |
|---|---|---|---|---|---|
/dev/random |
Linux 4.8 以降 (2016 年 10 月)、iOS、Android、その他の Linux ベースの POSIX オペレーティングシステムにもあります。RFC7539 に基づいています。 | ChaCha20 ストリームを利用します。iOS SecRandomCopyBytes および Android Secure Random にあり、それぞれに正しい設定が提供されています。 |
✓ | ✓ | ✓ |
/dev/urandom |
ランダムデータを提供するための Linux カーネルの特殊ファイルです。 | ハードウェアのランダム性から高性能のエントロピーソースを提供します。 | ✓ | ✓ | ✓ |
AES-CTR-DRBG |
NIST SP800-90A | BCRYPT_RNG_ALGORITHM で設定された Windows CNG API BCryptGenRandom などの一般的な実装で使用されます。 |
✓ | ✓ | ✓ |
HMAC-DRBG |
NIST SP800-90A | ✓ | ✓ | ✓ | |
Hash-DRBG |
NIST SP800-90A | ✓ | ✓ | ✓ | |
getentropy() |
OpenBSD、Linux glibc 2.25 以降、macOS 10.12 以降 で利用可能です。 | シンプルで最小限の API で、カーネルのエントロピーソースから安全なランダムバイトを直接提供します。より現代的であり、古い API に関連する落とし穴を回避します。 | ✓ | ✓ | ✓ |
以下は RBG に使用すべきではありません (SHOULD NOT) (NIST SP-800-57 Part 1 による):
| ハッシュ関数 | リファレンス |
|---|---|
| SHA3-224 | FIPS 202 |
| SHA-512/224 | FIPS 180-4 |
| SHA-224 | FIPS 180-4 |
| KMAC128 | NIST SP 800-185 |
以下の暗号が承認されています:
| 対称鍵アルゴリズム | リファレンス | L1 | L2 | L3 |
|---|---|---|---|---|
| AES-256 | FIPS 197 | ✓ | ✓ | |
| Salsa20 | Salsa 20 specification | ✓ | ✓ | |
| XChaCha20 | ✓ | ✓ | ✓ | |
| XSalsa20 | Extending the Salsa20 nonce | ✓ | ✓ | ✓ |
| ChaCha20 | RFC 8439 | ✓ | ✓ | ✓ |
| AES-192 | FIPS 197 | ✓ | ✓ | ✓ |
| AES-128 | FIPS 197 | ✓ | ✓ | ✓ |
以下は、明示的に許可されていない 暗号のリストです。上記のリストにないものは、文書化された理由とともに承認されなければなりませんが、以下は明示的に禁止されており、使用してはなりません (MUST NOT):
| 対称鍵アルゴリズム |
|---|
| 2TDEA |
| 3TDEA (3DES) |
| IDEA |
| RC4 |
| Blowfish |
| ARC4 |
| DES |
現代の暗号はさまざまな目的でさまざまなモード、特に AES を使用しています。ここでは AES 暗号モードの要件について説明します。
以下のモードは、その機能が暗号化されたデータ保存 (次のサブセクションを参照) である場合を除いて、承認されています:
| AES 暗号モード | 認証済み | リファレンス | L1 | L2 | L3 |
|---|---|---|---|---|---|
| GCM | Yes | NIST SP 800-38D | ✓ | ✓ | ✓ |
| CCM | Yes | NIST SP 800-38C | ✓ | ✓ | ✓ |
| CCM-8 | Yes | RFC 6655 | ✓ | ✓ | ✓ |
| CBC* | No | NIST SP 800-38A | ✓ | ✓ | ✓ |
* すべての暗号化されたメッセージは認証されなければなりません。このため、CBC モードを使用する場合は必ず、メッセージを検証するためにハッシュ関数または MAC が関連付けられていなければなりません (MUST)。一般的に、これは Encrypt-Then-Hash 方式で適用されなければなりません (MUST) (ただし、TLS 1.2 では代わりに Hash-Then-Encrypt を使用します)。これが保証できない場合、CBC を使用してはいけません (MUST NOT)。
指定の承認されたブロックモードのうち、実装ではこのリストの暗号を優先順に使用すべきです (SHOULD):
| AES 暗号モード | リファレンス | L1 | L2 | L3 |
|---|---|---|---|---|
| GCM | NIST SP 800-38D | ✓ | ✓ | ✓ |
| CCM | NIST SP 800-38C | ✓ | ✓ | ✓ |
以下のディスクレベルブロック暗号モードが承認されており、優先順にリストされています:
| AES ディスク暗号モード | リファレンス | L1 | L2 | L3 |
|---|---|---|---|---|
| XTS | NIST SP 800-38E | ✓ | ✓ | ✓ |
| XEX | Rogaway 2004 | ✓ | ✓ | ✓ |
| LRW | Liskov, Rivest, and Wagner 2005 | ✓ | ✓ | ✓ |
以下の暗号モードはいかなるユースケースでも使用してはいけません (MUST NOT):
| 暗号モード |
|---|
| ECB |
| CFB |
| OFB |
| CTR |
暗号鍵ラップ (および対応する鍵アンラップ) は、追加の暗号メカニズムを使用して既存の鍵をカプセル化 (つまりラップ) し、転送中などに元の鍵が明らかに露出しないようにすることで、既存の鍵を保護する方法です。元の鍵を保護するために使用されるこの追加の鍵はラップ鍵と呼ばれます。
この操作は、信頼できないとみなされる場所で鍵を保護したい場合、あるいは信頼できないネットワーク上やアプリケーション内で機密鍵を送信したい場合に実行できます。 ただし、ラップ/アンラップ手順を実行する前に、元の鍵の性質 (アイデンティティや目的など) を理解することを真剣に検討すべきです。これは、セキュリティと、特に鍵の機能 (署名など) の監査証跡や適切な鍵の保存を含むコンプライアンスの点で、ソースとターゲットの両方のシステム/アプリケーションに影響を及ぼす可能性があります。
鍵ラッピングには、NIST SP 800-38F に従い、量子脅威に対する将来を見据えた対策を考慮して、AES-256 のみを使用しなければなりません (MUST)。AES を使用する暗号モードは優先順に以下のとおりです:
| 鍵ラッピング | リファレンス | L1 | L2 | L3 |
|---|---|---|---|---|
| KW | NIST SP 800-38F | ✓ | ✓ | ✓ |
| KWP | NIST SP 800-38F | ✓ | ✓ | ✓ |
AES-192 と AES-128 はユースケースで必要な場合に使用できます (MAY) が、その理由はエンティティの暗号インベントリに文書化されなければなりません (MUST)。
以下のハッシュ関数は、デジタル署名、HMAC、鍵導出関数 (KDF)、ランダムビット生成 (RBG) などの一般的な暗号ユースケースでの使用が承認されています。これらの関数は強力な衝突耐性を提供し、高セキュリティアプリケーションに適しています。これらのアルゴリズムの一部は、適切な暗号鍵管理で使用すると攻撃に対する強力な耐性を提供するため、HMAC、KDF、RBG 機能でも承認されています。
| ハッシュ関数 | HMAC/KDF/RBG に適しているか？ | リファレンス | L1 | L2 | L3 |
|---|---|---|---|---|---|
| SHA3-512 | Y | FIPS 202 | ✓ | ✓ | |
| SHA-512 | Y | FIPS 180-4 | ✓ | ✓ | |
| SHA3-384 | Y | FIPS 202 | ✓ | ✓ | |
| SHA-384 | Y | FIPS 180-4 | ✓ | ✓ | |
| SHA3-256 | Y | FIPS 202 | ✓ | ✓ | |
| SHA-512/256 | Y | FIPS 180-4 | ✓ | ✓ | |
| SHA-256 | Y | FIPS 180-4 | ✓ | ✓ | ✓ |
| KMAC256 | N | NIST SP 800-185 | ✓ | ✓ | ✓ |
| KMAC128 | N | NIST SP 800-185 | ✓ | ✓ | ✓ |
| SHAKE256 | Y | FIPS 202 | ✓ | ✓ | ✓ |
| BLAKE2s | Y | ✓ | ✓ | ✓ | |
| BLAKE2b | Y | ✓ | ✓ | ✓ | |
| BLAKE3 | Y | ✓ | ✓ | ✓ |
以下のハッシュ関数は安全なパスワード保存に特に推奨されています。これらの低速ハッシュアルゴリズムは、パスワードクラッキングの計算難易度を上げることで、ブルートフォース攻撃や辞書攻撃を軽減します。
| ハッシュ関数 | リファレンス | 必要なパラメータセット | L1 | L2 | L3 |
|---|---|---|---|---|---|
| argon2 | RFC 9106 | Argon2ID: Memory Cost 19MB, Time Cost 2, Parallelism 1 | ✓ | ✓ | |
| scrypt | RFC 7914 | 2^15 r = 8 p = 1 | ✓ | ✓ | |
| bcrypt | -- | At least 10 rounds. | ✓ | ✓ | |
| PBKDF2_SHA512 | NIST SP 800-132, FIPS 180-4 | 210,000 iterations | ✓ | ✓ | ✓ |
| PBKDF2_SHA256 | NIST SP 800-132, FIPS 180-4 | 600,000 iterations | ✓ | ✓ | ✓ |
以下のハッシュ関数は、既知の弱点や脆弱性のため、新しいマテリアルを生成する暗号操作に使用してはいけません (MUST NOT)。既存のマテリアルの検証にのみ使用できます (MAY)。
| ハッシュ関数 | リファレンス |
|---|---|
| CRC (any length) | -- |
| MD4 | RFC 1320 |
| MD5 | RFC 1321 |
| SHA-1 | RFC 3174 & RFC 6194 |
デジタル署名の実装では、以下のハッシュ関数は衝突耐性が不十分なため使用してはいけません (MUST NOT)。
| ハッシュ関数 | リファレンス |
|---|---|
| SHA-224 | FIPS 180-4 |
| SHA-512/224 | FIPS 180-4 |
| SHA3-224 | FIPS 202 |
すべての鍵交換スキームに対して 112 ビット以上のセキュリティ強度が確保されていなければならず (MUST)、その実装は以下の表のパラメータ選択に従わなければなりません (MUST)。
| スキーム | ドメインパラメータ |
|---|---|
| RSA | k >= 2048 |
| Diffie-Hellman (DH) | L >= 2048 & N >= 224 |
| Elliptic Curve Diffie-Hellman (ECDH) | f >= 224 |
ここでのパラメータは以下のとおりです:
- k は RSA 鍵の鍵サイズです。
- L は有限体暗号の公開鍵 (public key) のサイズであり、N は秘密鍵 (private key) のサイズです。
- f は ECC の鍵サイズの範囲です。
以下のグループが承認されており、Diffie-Hellman KEX の実装に使用しなければなりません (MUST)。IKEv2 グループはリファレンスとして提供されています (NIST SP 800-77)。同等のグループが他のプロトコルで使用されるかもしれません。このリストは最も強力なものから最も弱いものの順に並べられています。セキュリティ強度は NIST SP 800-56A, Appendix D および NIST SP 800-57 Part 1 Rev.5 に記載されています。
| グループ | スキーム | パラメータ | セキュリティビット | L1 | L2 | L3 |
|---|---|---|---|---|---|---|
| 21 | ECC | 521-bit random ECP group | 260 | ✓ | ||
| 32 | ECC | Curve448 | 224 | ✓ | ||
| 18 | MODP | 8192-bit MODP Group | 192 < 200 | ✓ | ✓ | |
| 20 | ECC | 384-bit random ECP group | 192 | ✓ | ✓ | |
| 17 | MODP | 6144-bit MODP Group | 128 < 176 | ✓ | ✓ | ✓ |
| 16 | MODP | 4096-bit MODP Group | 128 < 152 | ✓ | ✓ | ✓ |
| 31 | ECC | Curve25519 | 128 | ✓ | ✓ | ✓ |
| 19 | ECC | 256-bit random ECP group | 128 | ✓ | ✓ | ✓ |
| 15 | MODP | 3072-bit MODP Group | 128 | ✓ | ✓ | ✓ |
| 14 | MODP | 2048-bit MODP Group | 112 | ✓ | ✓ | ✓ |
新しい実装では NIST SP 800-56A & B および NIST SP 800-77 に準拠していないスキームを使用してはいけません (MUST NOT)。
特に IKEv1 は本番環境で使用してはいけません (MUST NOT)。
メッセージ認証コード (MAC) は、メッセージの完全性と真正性を検証するために使用される暗号構造です。MAC は、メッセージと共有鍵 (secret key) を入力として受け取り、固定サイズのタグ (MAC 値) を生成します。MAC は安全な通信プロトコル (TLS/SSL など) で広く使用され、パーティ間で交換されるメッセージが本物で無傷であることを確保します。
以下の MAC アルゴリズムは、完全性と真正性の保証を提供することで、メッセージ保護に使用することが承認されています。実装では、メッセージのセキュリティを確保するために、認証された暗号モードまたは別途適用された HMAC のみを使用しなければなりません (MUST)。
| MAC アルゴリズム | リファレンス | 一般的な使用に適しているか？ | L1 | L2 | L3 |
|---|---|---|---|---|---|
| HMAC-SHA-256 | RFC 2104 & FIPS 198-1 | ✓ | ✓ | ✓ | ✓ |
| HMAC-SHA-384 | RFC 2104 & FIPS 198-1 | ✓ | ✓ | ✓ | |
| HMAC-SHA-512 | RFC 2104 & FIPS 198-1 | ✓ | ✓ | ✓ | |
| HMAC-SHA-1 | RFC 2104 & FIPS 198-1 | ✓ | ✓ | ✓ | |
| KMAC128 | NIST SP 800-185 | ✓ | ✓ | ✓ | ✓ |
| KMAC256 | NIST SP 800-185 | ✓ | ✓ | ✓ | ✓ |
| Blake3 | ✓ | ✓ | ✓ | ✓ |
SHA-1 は一般的に使用すべきではありませんが、HMAC-SHA-1 の使用は現時点では問題がないと考えられています (NIST SP 800-57)。
以下のアルゴリズムは、既知の脆弱性や不十分なセキュリティ強度のため、明示的に禁止されており、使用してはいけません (MUST NOT):
| MAC アルゴリズム | リファレンス |
|---|---|
| HMAC-MD5 | RFC 1321 |
以下のデジタル署名アルゴリズムは、データの真正性と完全性を確保するために使用することが承認されています。署名スキームは NIST SP 800-57 Part 1 に従って承認された鍵サイズとパラメータを使用しなければなりません (MUST):
| 署名アルゴリズム | リファレンス | 一般的な使用に適しているか？ | L1 | L2 | L3 |
|---|---|---|---|---|---|
| EdDSA (Ed25519, Ed448) | RFC 8032 | ✓ | ✓ | ✓ | ✓ |
| XEdDSA (Curve25519, Curve448) | XEdDSA | ✓ | ✓ | ✓ | ✓ |
| ECDSA (P-256, P-384, P-521) | FIPS 186-4 | ✓ | ✓ | ✓ | ✓ |
| RSA-RSSA-PSS | RFC 8017 | ✓ | ✓ | ✓ | ✓ |
以下のデジタル署名アルゴリズムは、既知の弱点や不十分なセキュリティ強度のため、使用してはいけません (MUST NOT):
| 署名アルゴリズム | リファレンス |
|---|---|
| RSA-SSA-PKCS#1 v1.5 | RFC 8017 |
| DSA (any key size) | FIPS 186-4 |
鍵導出関数は鍵マテリアルを特定の暗号操作に適した鍵に変換します。以下の KDF が承認されており、アプリケーションのニーズとセキュリティコンテキストに基づいて使用されなければなりません (MUST):
| KDF | リファレンス | 一般的な使用に適しているか？ | L1 | L2 | L3 |
|---|---|---|---|---|---|
| argon2id | RFC 9106 | ✓ | ✓ | ✓ | |
| scrypt | RFC 7914 | ✓ | ✓ | ✓ | |
| PBKDF2 | RFC 8018 & NIST SP 800-132 | ✓ | ✓ | ✓ | ✓ |
| HKDF | RFC 5869 | ✓ | ✓ | ✓ | ✓ |
以下の KDF は、不十分なセキュリティプロパティや既知の弱点のため、明示的に禁止されており、使用してはいけません (MUST NOT):
| KDF | リファレンス |
|---|---|
| MD5-based KDFs | RFC 1321 |
| SHA-1-based KDFs | RFC 3174 & RFC 6194 |
PQC 実装は FIPS-203/204/205 に準拠していなければなりませんが、堅牢化されたコードや実装リファレンスはまだ存在しません。 https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards