NIST SP 800-90A：DRBG標準

暗号処理には、高品質な乱数が必要です。たとえば、鍵の生成、nonce、IV、salt、セッショントークンなどです。真の乱数生成器（TRNG）は、ハードウェアノイズ、割り込み、熱雑音などの物理的な発生源からエントロピーを収集しますが、低速であり、特に仮想マシンやブート直後の環境では常に利用できるとは限りません。決定論的ランダムビット生成器（DRBG）はこの問題を解決します。少量の真のエントロピーでDRBGをシードし、暗号アルゴリズムを使って、それを真の乱数と計算量的に識別できない大量の疑似乱数ビットへ引き伸ばします。NIST SP 800-90Aでは、現代のほぼすべての暗号実装で使用される、承認済みの3種類のDRBGメカニズムを定義しています。

DRBGは、3つの基本操作で動作します。Instantiate：エントロピー源から得たentropy_input、nonce（値の一意性を保証する一度限りの値）、およびオプションのpersonalization_string（アプリケーション固有のコンテキスト）を使って、DRBGの内部状態を初期化します。Generate：要求された数の疑似乱数ビットを生成し、バックトラッキングを防ぐために内部状態を更新します。Reseed：新しいエントロピーをDRBGの状態に注入して予測耐性を提供します。Reseed後は、以前の状態を知っていた攻撃者であっても、将来の出力を予測できません。NISTは最大のGenerate間隔（reseed_interval）を規定しており、3種類すべてのDRBGで、再シードを必須とするまでのリクエスト数は2^48です。

NIST SP 800-90Aでは、112、128、192、256ビットという4つのセキュリティ強度レベルを定義しています。セキュリティ強度によって、初期化時に必要な最小エントロピー量と、生成される出力の品質が決まります。128ビットのセキュリティでは、エントロピー入力が少なくとも128ビットのエントロピーを提供する必要があります。関係は次のとおりです：security_strengthビットのエントロピー -> 2^security_strength回の操作を行う攻撃者に対して、DRBGの出力が乱数と計算量的に識別できない。鍵長の選択（AES-128対AES-256）とハッシュの選択（SHA-256対SHA-512）は、必要なセキュリティ強度と同等以上になるよう制約されます。過剰なパラメーター設定（128ビットのセキュリティにSHA-512を使用）は安全ですが無駄があり、パラメーター不足はセキュリティを損ないます。

Hash_DRBGは、2つの状態値を保持します。V（出力を生成する値）とC（Generate中に加算される定数）です。Generateでは、hash_genがH(0x01 || V)、H(0x01 || V+1)、...を十分な出力が得られるまで繰り返し計算します。その後、VをV = V + H(0x03 || V) + C + reseed_counterで更新します。Reseedでは、Hash_df（ハッシュ導出関数）を使用し、現在のVと新しいエントロピーを組み合わせて新しいVとCを生成します。Hash_DRBGは実装が容易でセキュリティ分析も単純なため、リソースが制限された環境に適しています。NISTは、SHA-256またはSHA-512による初期化を推奨しています。Hash_DRBGは、JavaのSHA1PRNG（旧版）やOpenSSLのlegacy DRBGで使用されています。

HMAC_DRBGは、状態（Key K、Value V）を保持します。Generateでは、十分な出力が生成されるまでV = HMAC(K, V)を繰り返し計算し、その後K = HMAC(K, V || 0x00)およびV = HMAC(K, V)で更新します。Updateでは、additional_inputを受け取り、HMAC操作を使ってKとVを再シードします。HMAC_DRBGには、HMACのセキュリティ（HMACに関するPRF仮定）に基づく明快なセキュリティ証明があります。これは最も広く推奨されているDRBGであり、OpenSSL（1.1.1以降）、mbedTLS、wolfSSL、およびほとんどのTLSスタックで使用されています。HMAC構成では連続する呼び出し間で組み込みの混合が行われるため、状態が部分的に露出した場合でも、バックトラッキング攻撃を仕掛けることが難しくなります。

CTR_DRBGは、ブロック暗号（AES）をカウンターモードで使用します。状態はKey KとカウンタVです。Generateでは、連続するカウンタ値E(K, V)、E(K, V+1)、...を暗号化し、Vをインクリメントします。Updateでは、Block_Cipher_dfを使ってadditional_inputから新しいKとVを導出します。CTR_DRBGは最も高速なDRBGです。AES-NIによるハードウェアアクセラレーションにより、現代のプロセッサではハッシュベースのDRBGより桁違いに高速です。Windows CNG（CryptGenRandomはAES-256を使用するCTR_DRBGを使用）、OpenSSL 3.0（デフォルト）、LinuxカーネルRNG（getrandom syscall）では、CTR_DRBGがデフォルトのDRBGです。CTR_DRBGのセキュリティは、AESが疑似ランダム置換であることに依存しており、これは数十年にわたる分析によって十分に裏付けられています。

予測耐性とは、Reseedによって新しいエントロピーが混合されることを条件に、過去にDRBGの状態を侵害した攻撃者に対してもDRBGの出力が予測不能になる性質です。prediction_resistance_flag=trueのDRBGは、各Generate呼び出しの前にエントロピー源を呼び出して新しいエントロピーを注入します。予測耐性がない場合、時刻Tに状態を侵害されると、将来のすべての出力を計算できてしまいます（前方秘匿性が破られます）。後方セキュリティ（backtracking resistanceとも呼ばれます）とは、現在の状態が知られていても過去の出力を予測できない性質です。HMAC_DRBGとCTR_DRBGは、各Generateの後に現在の状態から新しい鍵を導出する更新ステップによって、この性質を実現しています。

SP 800-90AはDRBGアルゴリズムを規定しますが、エントロピー源については規定していません。SP 800-90Bはエントロピー源の要件を定義しています。ハードウェアノイズ源は特性評価と検証を行い、エントロピーの推定値は保守的にし、ヘルステストでエントロピー源の障害を検出する必要があります。SP 800-90Cは、エントロピー源とDRBGを組み合わせて完全なランダムビット生成器にする方法を規定しています。代表的なエントロピー源には、CPUのRDRAND/RDSEED（ハードウェアRNG、2012年以降のIntel/AMD CPUで利用可能）、OSのエントロピー（Linuxの/dev/urandom、WindowsのBCryptGenRandom）、ハードウェアセキュリティモジュール、TPM 2.0 RNG、環境ノイズ（ディスクのタイミング、ネットワークジッター）があります。エントロピーが少ない状況（仮想マシンやブート直後）では、弱いシードを避けるために特別な処理が必要です。

FIPS 140-3（暗号モジュールの検証に関する現行標準）は、認証済みモジュール内のすべての乱数生成にNIST SP 800-90AのDRBGを義務付けています。モジュールは、承認済みのDRBG（Hash、HMAC、またはCTR）を使用し、SP 800-90Bの要件を満たす承認済みエントロピー源からシードを取得し、DRBGの動作を検証する電源投入時自己テスト（POST）を実行し、エントロピー源の0固定または1固定の障害を検出する連続RNGテスト（CRNGT）を実装し、エントロピー源が利用可能なエントロピーを示したときにReseedをサポートする必要があります。HSM（Thales Luna、AWS CloudHSM、Utimaco）、TLSアクセラレータカード、ネットワーク暗号化アプライアンスでは、FIPS 140-3検証済みモジュールが一般的に必要とされるため、SP 800-90Aの採用が進んでいます。

現代のオペレーティングシステムは、ハードウェアのエントロピー源からシードされたカーネルレベルのDRBGを維持しています。LinuxはRDRAND、割り込み、ディスクやネットワークのイベントを元にシードするChaCha20ベースのDRBGを使用します（カーネル5.17以降。以前のFortunaに類似した設計から置き換えられました）。/dev/urandomはDRBGの出力を返し、最初にシードされた後はブロックしません。/dev/randomは、十分なエントロピーが利用可能になるまでブロックします（従来の動作であり、最近のカーネルではほとんど廃止されています）。getrandom(2)システムコールは現代的なインターフェースであり、DRBGがシードされる前のブート初期段階でのみブロックします。Windowsは、TPMとハードウェアイベントからシードされたカーネルRNGでCTR_DRBG（AES-256）を使用します。アプリケーションは、タイムスタンプやPIDから独自のDRBGにシードするのではなく、高レベルAPIを介してOSのDRBGを使用する必要があります。

現実世界でのDRBGの脆弱性は、アルゴリズムの弱点ではなく、実装上のエラーから生じます。(1) 不十分なシード：現在のタイムスタンプやPIDだけを使ってシードすると、攻撃者に推測可能なシードになります。(2) fork blindness：プロセスがforkすると、親プロセスと子プロセスが同じDRBG状態を共有するため、同一の乱数を生成します。対策：fork後に再シードします（pthread_atforkまたは明示的なgetrandom呼び出し）。(3) VMスナップショットの再利用：VMスナップショットが復元されると、DRBGの状態もスナップショット時の状態に戻り、以前に見た出力が生成されます。対策：VMの起動時に一意のエントロピーを注入します（VIRTIO RNG）。(4) 健全性テストの失敗を黙って無視すること：エントロピー障害を検出した後も生成を続けるDRBGは、攻撃者に予測可能な出力を提供します。(5) DRBGインスタンス間でnonceを再利用すること。

新しいエントロピーでDRBGを再シードすると、どのような性質が得られますか？

NIST SP 800-90Aは、承認済みの3つのDRBGメカニズムを定義しています：Hash_DRBG（反復ハッシュ、単純）、HMAC_DRBG（HMACベース、明快なセキュリティ証明、広く導入）、CTR_DRBG（AESカウンターモード、AES-NIによって最速、Windows/OpenSSLのデフォルト）。3つすべてが、reseed_intervalを2^48に制限したInstantiate/Generate/Reseedのライフサイクルを共有します。セキュリティ強度（112～256ビット）が必要なエントロピー量を決めます。予測耐性には、Generate呼び出しごとに前もって再シードする必要があります。FIPS 140-3では、SP 800-90Bのエントロピー源と組み合わせたSP 800-90A DRBGが義務付けられています。fork blindness、VMスナップショットの再利用、不十分なシードが、現実世界での主な実装上の落とし穴です。