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

2025-04-02

この情報は、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 など、他のすべてのブロック暗号を置き換える必要があります。

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

暗号モード

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

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

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

出力フィードバック (OFB)
暗号フィードバック (CFB)
Counter (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 ガイドラインに従うことをお勧めします。呼び出しの最大数に関するセクション 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)。

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

RSA

RSA は、暗号化、キー交換、署名に使用できます。
RSA 暗号化では、OAEP または RSA-PSS パディングモードを使用する必要があります。
既存のコードでは、互換性のためにのみ PKCS #1 v1.5 パディングモードを使用する必要があります。
null パディングの使用は推奨されません。
少なくとも 2048 ビットのキー長をお勧めしますが、3072 ビットのキー長をサポートすることをお勧めします。

ECDSA と ECDH

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

整数 Diffie-Hellman

キー長 >= 2048 ビットが推奨されます0
グループパラメーターは、既知の名前付きグループ (RFC 7919 など) であるか、信頼されたパーティによって生成され、使用する前に認証される必要があります。

キーの有効期間

すべてのキーの暗号期間を定義します。
- たとえば、データ暗号化の対称キー (多くの場合、データ暗号化キーまたは DEK と呼ばれます) には、データを暗号化するための使用期間が最大 2 年 (発信元の使用期間とも呼ばれます) がある場合があります。暗号化解除の有効な使用期間が、受信者の使用期間とも呼ばれる、さらに 3 年間存在することを定義できます。
限られたアクティブな有効期間を実現するために、キーを置き換えるメカニズムまたはプロセスを用意する必要があります。アクティブな有効期間が終了した後は、キーを使用して新しいデータ (暗号化や署名など) を生成することはできませんが、データの読み取り (暗号化解除や検証など) には引き続き使用できます。

乱数ジェネレーター

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

CNG

BCryptGenRandom を BCRYPT_USE_SYSTEM_PREFERRED_RNG フラグと共に使用します。

Win32/64

レガシコードでは、カーネルモード RtlGenRandom を使用できます。
新しいコードでは、BCryptGenRandom または CryptGenRandomを使うべきです。
C 関数 Rand_s() も推奨されます (Windows では CryptGenRandom 呼び出します)。
Rand_s() は、Rand() の安全でパフォーマンスの高い代替品です。
Rand() は、暗号化アプリケーションには使用できません。

.NET

RandomNumberGenerator を使用します。

PowerShell

Get-SecureRandom (PowerShell)を使用します。

Windows ストアアプリ

Windows ストアアプリでは、CryptographicBuffer.GenerateRandom または CryptographicBuffer.GenerateRandomNumber を使用できます。

Linux/macOS

/dev/urandom デバイスは、getrandom(2) システム呼び出しと同様に、暗号的に強力なランダムデータソースを提供します。

お勧めしません

乱数生成に関連する安全でない関数には、rand、System.Random (.NET)、GetTickCount、GetTickCount64、Get-Random (PowerShell コマンドレット)があります。
二重楕円曲線乱数ジェネレーター ("DUAL_EC_DRBG") アルゴリズムの使用は許可されていません。

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

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

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

ライブラリは、既知のセキュリティ脆弱性を含まない現在のサポート内バージョンである必要があります。
最新のセキュリティプロトコル、アルゴリズム、キーの長さをサポートする必要があります。
(省略可能)ライブラリは、下位互換性のためにのみ、以前のセキュリティプロトコル/アルゴリズムをサポートできる必要があります。

ネイティブコード

暗号化プリミティブ: リリースが Windows 上にある場合は、可能であれば CNG を使用します。
コード署名の検証: WinVerifyTrust は、Windows プラットフォームでコード署名を検証するためにサポートされている API です。
証明書の検証 (コード署名または SSL/TLS/DTLS の制限付き証明書検証で使用される): CAPI2 API;たとえば、CertGetCertificateChain と CertVerifyCertificateChainPolicyします。

マネージドコード (.NET)

暗号化プリミティブ: System.Security.Cryptography 名前空間で定義されている API を使用します。
使用可能な最新バージョンの .NET を使用します。

主要な派生関数

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

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

NIST SP 800-108 (リビジョン 1): 擬似乱数関数を使用したキー派生に関する推奨事項。特に、KDF はカウンターモードで、HMAC は擬似乱数関数として使用されます。
NIST SP 800-56A (リビジョン 3): 離散対数暗号を使用した Pair-Wise キー確立スキームに関する推奨事項。

既存のキーからキーを派生するには、次のいずれかのアルゴリズムで 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 をサポートすることをお勧めします。

HMAC を 128 ビット未満に切り捨てることは推奨されません。

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

必要に応じて、暗号化キーを置き換えるメカニズムを提供する必要があります。キーは、アクティブな有効期間が終了するか、暗号化キーが侵害されたら置き換える必要があります。
- 証明書を更新するたびに、新しいキーで証明書を更新する必要があります。
暗号化アルゴリズムを使用してデータを保護する製品には、将来的にさまざまなアルゴリズムへの移行をサポートするために、十分なメタデータとそのコンテンツが含まれている必要があります。このメタデータには、使用されるアルゴリズム、キーサイズ、パディングモードを含める必要があります。
- 暗号化の機敏性の詳細については、暗号化の機敏性記事を参照してください。
利用可能な場合、製品では、署名形式 (標準の既存の形式を使用するなど) を含め、それらを再実装するのではなく、確立されたプラットフォームで提供される暗号化プロトコルを使用する必要があります。
暗号化操作の失敗をエンドユーザーに報告しないでください。リモート呼び出し元にエラーを返す場合 (たとえば、Web クライアント、クライアントサーバーのシナリオではクライアント)、汎用エラーメッセージのみを使用します。
- 範囲外のエラーや無効な長さのエラーを直接報告するなど、不要な情報を指定しないでください。詳細ログが有効になっている場合に限り、サーバー側でのみ詳細エラーをログに記録します。
次の項目を組み込んだ設計では、追加のセキュリティレビューを強くお勧めします。
- 主にセキュリティに重点を置いた新しいプロトコル (認証プロトコルや承認プロトコルなど)
- 新しい方法または非標準の方法で暗号化を使用する新しいプロトコル。考慮事項の例を次に示します。
  - プロトコルを実装する製品は、プロトコル実装の一部として任意の暗号化 API またはメソッドを呼び出しますか?
  - プロトコルは、認証または承認に使用される他のプロトコルに依存していますか?
  - プロトコルは、キーなどの暗号化要素のストレージ形式を定義しますか?
自己署名証明書は推奨されません。生の暗号化キーの使用など、自己署名証明書を使用しても、本質的にユーザーや管理者は信頼の決定を行う基礎を提供しません。
- これに対し、信頼できる証明機関にルート化された証明書を使用すると、関連付けられている秘密キーに依存する基礎が明確になり、セキュリティエラーが発生した場合に失効と更新が有効になります。