次の方法で共有

Microsoft SDL 暗号化に関する推奨事項

この情報は、Microsoft が独自の製品とサービスに必要とするのと同じ API、アルゴリズム、プロトコル、およびキーの長さを使用するように製品を設計する場合に参照として使用します。 コンテンツの多くは、セキュリティ開発ライフサイクルの作成に使用される Microsoft 独自の内部セキュリティ標準に基づいています。

Windows 以外のプラットフォームの開発者は、これらの推奨事項の恩恵を受ける可能性があります。 API とライブラリの名前は異なる場合があります。アルゴリズムの選択、キーの長さ、データ保護に関するベスト プラクティスは、プラットフォーム間で似ています。

セキュリティ プロトコル、アルゴリズム、キーの長さの推奨事項

TLS/SSL バージョン

製品とサービスでは、暗号化によってセキュリティで保護されたバージョンの TLS/SSL を使用する必要があります。

  • TLS 1.3 を有効にする必要がある

  • TLS 1.2 を有効にして、古いクライアントとの互換性を向上させることができます。

  • TLS 1.1、TLS 1.0、SSL 3、SSL 2 を無効にする必要があります

対称ブロック暗号、暗号モード、および初期化ベクトル

ブロック暗号

対称ブロック暗号を使用する製品の場合:

  • Advanced Encryption Standard (AES) が必要です。

  • 暗号化に使用する場合は、3DES (Triple DES/TDEA) や RC4 など、他のすべてのブロック暗号を置き換える必要があります。

対称ブロック暗号化アルゴリズムの場合は、256 ビット キーをサポートすることをお勧めしますが、最大 128 ビットを使用できます。 新しいコードに推奨される唯一のブロック暗号化アルゴリズムは AES です (AES-128、AES-192、AES-256 はすべて許容可能であり、AES-192 には一部のプロセッサでの最適化がないことを示しています)。

暗号モード

対称アルゴリズムはさまざまなモードで動作できます。そのほとんどは、プレーンテキストと暗号テキストの連続するブロックに対する暗号化操作をリンクします。

対称ブロック暗号は、次のいずれかの暗号モードで使用する必要があります。

次のような他の暗号モードには、誤って使用される可能性が高い実装の落とし穴があります。 特に、電子コードブック (ECB) の動作モードは避ける必要があります。 CTR などの "ストリーミング暗号モード" でブロック暗号を使用して同じ初期化ベクトル (IV) を再利用すると、暗号化されたデータが表示される可能性があります。 次のいずれかのモードを使用する場合は、追加のセキュリティ レビューをお勧めします。

  • 出力フィードバック (OFB)

  • 暗号フィードバック (CFB)

  • カウンター (CTR)

  • 上記の上記の "推奨" リストに含まれていないもの

初期化ベクトル (IV)

すべての対称ブロック暗号は、暗号化的に強力な乱数を初期化ベクトルとして使用する必要もあります。 初期化ベクトルを定数または事前指定可能な値にしないでください。 暗号強度の高い乱数の生成に関する推奨事項については、「乱数ジェネレーター」を参照してください。

初期化ベクターは、複数の暗号化操作を実行するときに再利用しないでください。 再利用すると、特に出力フィードバック (OFB) やカウンター (CTR) などのストリーミング暗号モードを使用する場合に、暗号化されているデータに関する情報を明らかにできます。

AES-GCM と AES-CCM の推奨事項

AES-GCM (Galois/Counter Mode) と AES-CCM (CBC-MACを持つカウンター) は、認証された暗号化モードで広く使用されています。 機密性と整合性の保護を組み合わせることで、セキュリティで保護された通信に役立ちます。 しかし、その脆弱性は nonce の再利用にあります。 同じ nonce (初期化ベクトル) を 2 回使用すると、致命的な結果につながる可能性があります。

NIST SP 800-38D、ブロック暗号モードの推奨:Galois/Counter Mode (GCM)、GMAC で説明されている nonce ガイドラインに従うことをお勧めします。キーと nonce/IV の一意性要件に関するセクション 8.1、8.2、および 8.3 に特に注意してください。

もう 1 つのオプションは、暗号化されるすべてのメッセージに対して一意の AES-GCM/CCM キーを生成し、呼び出しの最大数を実質的に 1 に制限することです。 データを保管時に暗号化する方法としてこのアプローチが推奨されます。カウンターを使用したり、特定のキーの使用回数を追跡したりすることは現実的ではありません。

保存データを暗号化する場合は、Encrypt-then-MAC スキームを使用して、メッセージ認証コード (MAC) と AES-CBC を併用することも検討できます。その際は、暗号化と MAC に別々のキーを使用するようにしてください。

整合性の検証

既定では、暗号化によって機密性と整合性の保証の両方が提供されるという一般的な誤解です。 多くの暗号化アルゴリズムは整合性チェックを提供せず、改ざん攻撃に対して脆弱な可能性があります。 送信前と受信後にデータの整合性を確保するために、追加の手順を実行する必要があります。

AES-GCM などの関連付けられたデータ (AEAD) で認証された暗号化アルゴリズムを使用できない場合は、暗号化と MAC のスキームを使用してメッセージ認証コード (MAC) で整合性を検証し、暗号化と MAC 用に個別のキーを使用する方法もあります。

暗号化と MAC には別のキーを使用することが不可欠です。 2 つのキーを格納できない場合、有効な代替方法は、適切なキー派生関数 (KDF) を使用してメイン キーから 2 つのキーを派生することです。1 つは暗号化目的で、もう 1 つは MAC 用です。 詳細については、「SP 800-108 Rev. 1、疑似乱数関数を使用した鍵導出に関する推奨事項 | CSRC (nist.gov)](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf。

非対称アルゴリズム、キーの長さ、およびパディング モード

RSA

  • RSA は、キートランスポート、キー交換、署名に使用できます。

  • RSA 暗号化では、OAEP または RSA-PSS パディング モードを使用する必要があります。

  • 既存のコードでは、署名に PKCS #1 v1.5 パディング モードを使用できます。

  • 暗号化に PKCS#1 v1.5 を使用することはできません。

  • null パディングの使用は推奨されません。

  • 2048 ビットのキー長が最小ですが、3072 ビットのキー長をサポートすることをお勧めします。

ECDSA と ECDH

  • ECDH ベースのキー交換と ECDSA ベースの署名では、NIST が承認した 3 つの曲線 (P-256、P-384、または P521) のいずれかを使用する必要があります。

  • P-256 のサポートは最小と見なす必要がありますが、P-384 のサポートをお勧めします。

ML-DSA

  • FIPS 204 標準を使用する必要があります。 ドラフト標準のバージョンは使用しないでください。

  • クラシック署名アルゴリズム (ECDSA または RSA) と組み合わせて ML-DSA を使用することをお勧めします。 相互運用性のためには、 IETF (ドラフト) またはその他の標準で定義されたコンバイナーを使用することをお勧めします。

  • ML-DSA の場合、有効なハイブリッド (複合) メカニズムは、クラシックと ML-DSA の両方で同じデータに署名し、両方を検証することです (いずれかの検証が失敗した場合、検証は失敗します)。

ML-KEM

  • FIPS 203 標準を使用する必要があります。 ドラフト標準のバージョンは使用しないでください。

  • ML-KEM と従来の KEM アルゴリズム (ECDH) を組み合わせたコンバイナーまたはハイブリッド暗号化システムを使用することをお勧めします。 相互運用性のためには、 IETF (ドラフト) またはその他の標準で定義されたコンバイナーを使用することをお勧めします。

SLH-DSA

  • FIPS 205 標準を使用する必要があります。 草案版標準のバージョンは使用しないでください。

  • SLH-DSA パラメーター セットはすべて許可されますが、推奨されるパラメーター セットはユース ケースによって異なります。

  • SHA-2 バージョンと SHAKE (SHA-3) バージョンの間に既知のセキュリティの違いはありません

LMS と XMSS

  • 署名検証では LMS または XMSS をサポートしても安全です。

  • 署名とキー生成用のインフラストラクチャを実装またはデプロイする前に、主題の専門家に相談することを強くお勧めします。 弱点はわかっていませんが、状態を適切に管理することが重要であるため、人間によるエラーは非常に可能で簡単です。

整数 Diffie-Hellman

  • 整数 Diffie-Hellman (DH) はキー交換に対して承認されていますが、最新の標準では最も効率的ではありません。 代わりに ECDH を使用することを強くお勧めします。
  • キー長 >= 2048 ビットが推奨されます0
  • グループ パラメーターは、既知の名前付きグループ (RFC 7919 など) であるか、信頼されたパーティによって生成され、使用する前に認証される必要があります。

キーの有効期間

  • すべてのキーの 暗号期間 を定義します。

    • たとえば、データ暗号化の対称キー (多くの場合、データ暗号化キーまたは DEK と呼ばれます) には、データを暗号化するための使用期間が最大 2 年 (発信元の使用期間とも呼ばれます) がある場合があります。 暗号化解除の有効な使用期間が、受信者の使用期間とも呼ばれる、さらに 3 年間存在することを定義できます。

  • 限られたアクティブな有効期間を実現するために、キーを置き換えるメカニズムまたはプロセスを用意する必要があります。 アクティブな有効期間が終了した後は、キーを使用して新しいデータ (暗号化や署名など) を生成することはできませんが、データの読み取り (暗号化解除や検証など) には引き続き使用できます。

乱数ジェネレーター

ランダム性が必要な場合は、すべての製品とサービスで暗号でセキュリティで保護された乱数ジェネレーターを使用する必要があります。

CNG

  • BCRYPT_USE_SYSTEM_PREFERRED_RNG フラグで BCryptGenRandom を使用します。

Win32/64

  • レガシ コードでは、カーネル モード RtlGenRandom を使用できます。

  • 新しいコードでは、BCryptGenRandom または CryptGenRandomを使うべきです。

  • C 関数 Rand_s() も推奨されます (Windows では CryptGenRandom 呼び出します)。

  • Rand_s() は、Rand() の安全でパフォーマンスの高い代替品です。

  • Rand() は、暗号化アプリケーションには使用できません。

.NET

PowerShell

Windows ストア アプリ

Windows プラットフォームでサポートされている暗号化ライブラリ

Windows プラットフォームでは、オペレーティング システムに組み込まれている暗号化 API を使用することをお勧めします。 他のプラットフォームでは、開発者は、使用するプラットフォーム以外の暗号化ライブラリを評価することを選択できます。 一般に、プラットフォーム暗号化ライブラリは、アプリケーションにバンドルされるのではなく、オペレーティング システムの一部として出荷されるため、より頻繁に更新されます。

プラットフォームとプラットフォーム以外の暗号化に関する使用上の決定は、次の要件に従う必要があります。

  • ライブラリは、既知のセキュリティ脆弱性を含まない現在のサポート内バージョンである必要があります。

  • 最新のセキュリティ プロトコル、アルゴリズム、キーの長さをサポートする必要があります。

  • (省略可能)ライブラリは、下位互換性のためにのみ、以前のセキュリティ プロトコル/アルゴリズムをサポートできる必要があります。

ネイティブ コード

  • 暗号化プリミティブ: リリースが Windows 上にある場合は、可能であれば CNG を使用します。

  • コード署名の検証: WinVerifyTrust は、Windows プラットフォームでコード署名を検証するためにサポートされている API です。

  • 証明書の検証 (コード署名または TLS/DTLS の制限付き証明書検証で使用): CAPI2 API;たとえば、 CertGetCertificateChain と CertVerifyCertificateChainPolicy です。

主要な派生関数

キーの派生は、共有シークレットまたは既存の暗号化キーから暗号化キー マテリアルを派生するプロセスです。 製品では、推奨されるキー派生関数を使用する必要があります。 ユーザーが選択したパスワードからキーを派生させたり、認証システム内のストレージ用のパスワードをハッシュしたりすることは、このガイダンスでは扱わない特殊なケースです。開発者は専門家に相談する必要があります。

次の標準では、使用するために推奨される KDF 関数を指定します。

既存のキーからキーを派生するには、次のいずれかのアルゴリズムで BCryptKeyDerivation API を使用します。

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

共有シークレット (キー アグリーメントの出力) からキーを派生するには、次のいずれかのアルゴリズムで BCryptDeriveKey API を使用します。

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

証明書の検証

TLS または DTLS を使用する製品では、接続先のエンティティの X.509 証明書を完全に検証する必要があります。 このプロセスには、証明書の次の部分の検証が含まれます。

  • ドメイン名。

  • 有効期間 (開始日と有効期限の両方)。

  • 失効状態。

  • 使用法 (サーバーの場合は "サーバー認証"、クライアントの場合は "クライアント認証" など)。

  • 信頼チェーン。 証明書は、プラットフォームによって信頼されているか、管理者によって明示的に構成されたルート証明機関 (CA) にチェーンする必要があります。

これらの検証テストのいずれかが失敗した場合、製品はエンティティとの接続を終了する必要があります。

"自己署名" 証明書は使用しないでください。 自己署名は、本質的に信頼、サポート失効、またはサポート キーの更新を伝えるわけではありません。

暗号化ハッシュ関数

製品では、SHA-2 ファミリのハッシュ アルゴリズム (SHA-256、SHA-384、SHA-512) を使用する必要があります。 セキュリティ目的で暗号化ハッシュを 128 ビット未満に切り捨てることは許可されません。 SHA-256 の使用は最小限ですが、SHA-384 をサポートすることをお勧めします。

MAC/HMAC/キー付きハッシュ アルゴリズム

メッセージ認証コード (MAC) は、受信者が秘密キーを使用して送信者の信頼性とメッセージの整合性の両方を確認できるようにする、メッセージに添付された情報の一部です。

ハッシュベースの MAC (HMAC) または ブロック暗号ベースの MAC の使用をお勧めします。ただし、すべての基礎となるハッシュまたは対称暗号化アルゴリズムも使用が推奨されている場合に限ります。現在、これには HMAC-SHA2 関数 (HMAC-SHA256、HMAC-SHA384、および HMAC-SHA512) が含まれています。 HMAC-SHA256 の使用は最小限ですが、HMAC-SHA384 をサポートすることをお勧めします。

128 ビット未満への HMAC の切り捨ては推奨されません。

設計と運用に関する考慮事項

  • 必要に応じて、暗号化キーを置き換えるメカニズムを提供する必要があります。 キーは、アクティブな有効期間が終了するか、暗号化キーが侵害されたら置き換える必要があります。

    • 証明書を更新するたびに、新しいキー (キーの更新) で証明書を更新する必要があります。

  • 暗号化アルゴリズムを使用してデータを保護する製品には、将来的にさまざまなアルゴリズムへの移行をサポートするために、十分なメタデータとそのコンテンツが含まれている必要があります。 このメタデータには、使用されるアルゴリズム、キー サイズ、パディング モードを含める必要があります。

    • 暗号化の機敏性の詳細については、暗号化の機敏性 記事を参照してください。

  • 利用可能な場合、製品では、署名形式 (標準の既存の形式を使用するなど) を含め、それらを再実装するのではなく、確立されたプラットフォームで提供される暗号化プロトコルを使用する必要があります。

  • 暗号化操作の失敗をエンド ユーザーに報告しないでください。 リモート呼び出し元にエラーを返す場合 (たとえば、Web クライアント、クライアント サーバーのシナリオではクライアント)、汎用エラー メッセージのみを使用します。

    • 範囲外のエラーや無効な長さのエラーを直接報告するなど、不要な情報を指定しないでください。 詳細ログが有効になっている場合に限り、サーバー側でのみ詳細エラーをログに記録します。

  • 次の項目を組み込んだ設計では、追加のセキュリティ レビューを強くお勧めします。

    • 主にセキュリティに重点を置いた新しいプロトコル (認証プロトコルや承認プロトコルなど)

    • 新しい方法または非標準の方法で暗号化を使用する新しいプロトコル。 考慮事項の例を次に示します。

      • プロトコルを実装する製品は、プロトコル実装の一部として任意の暗号化 API またはメソッドを呼び出しますか?

      • プロトコルは、認証または承認に使用される他のプロトコルに依存していますか?

      • プロトコルは、キーなどの暗号化要素のストレージ形式を定義しますか?

  • 自己署名証明書は推奨されません。 生の暗号化キーの使用など、自己署名証明書を使用しても、本質的にユーザーや管理者は信頼の決定を行う基礎を提供しません。

    • これに対し、信頼できる証明機関にルート化された証明書を使用すると、関連付けられている秘密キーに依存する基礎が明確になり、セキュリティエラーが発生した場合に失効と更新が有効になります。
  • Last updated on