【SC試験】乱数生成の脆弱性 — 疑似乱数と暗号論的安全性 問題セット

正解： ア

解説：

• ア）正解。真性乱数は放射性崩壊のタイミング、熱雑音、大気ノイズなど物理現象由来のエントロピー（不確実性）を元に生成される乱数であり、原理的に再現性を持ちません。これに対し疑似乱数はアルゴリズムによる決定論的な計算で生成されます。
• イ）不正解。前半の「同一シードから同一数列が再現される」という性質自体は正しいですが、この性質は暗号鍵生成やセッションIDの発行など「予測不可能性」が求められる用途では致命的な弱点になります。「どのような用途でも問題にならない」という結論は誤りです。
• ウ）不正解。暗号用途においては、生成方式の違いが安全性に直結します。一般的なPRNG（線形合同法等）は数列から内部状態を逆算できる場合があり、暗号論的に安全とはみなされません。真性乱数や暗号論的疑似乱数生成器（CSPRNG）を用いる必要があります。
• エ）不正解。システム起動時刻のような予測が容易な値をシードに使うと、攻撃者がシード値を推測でき、生成される乱数列（延いては暗号鍵等）を再現される危険があります。シードにはエントロピーの高い予測困難な値を使うべきです。

正解： イ

解説：

• ア）不正解。CSPRNGには統計的偏りのなさに加えて、「次の出力予測不可能性（next-bit test：過去の出力列から次のビットを有意に高い確率で予測できないこと）」という暗号学的要件が課されます。メルセンヌ・ツイスタのような一般的PRNGは統計的性質は優れていても、内部状態が推測されると将来の出力が予測できてしまうため、CSPRNGとしては不適格です。
• イ）正解。CSPRNGには「過去の出力が漏れても将来の出力を予測できない（前方予測不可能性）」「現在の内部状態が漏れても過去の出力を逆算できない（後方予測不可能性、Backtracking Resistance）」という2つの性質が求められます。これにより一時的な内部状態の漏えいが起きても被害を限定できます。
• ウ）不正解。OSが提供する/dev/urandomやBCryptGenRandom（Windows）はCSPRNGとして設計・実装された標準APIであり、暗号用途に適した乱数源として広く推奨されています。「独自実装すべき」という記述は誤りであり、実務では車輪の再発明（独自の乱数アルゴリズム実装）はむしろ脆弱性の温床になりがちなため避けるべきとされています。
• エ）不正解。rand()関数やメルセンヌ・ツイスタは統計的品質は高くても暗号論的安全性（予測不可能性）を満たさないため、シード値を秘匿しても出力列から内部状態が推測されるリスクが残ります。暗号鍵やセッションIDの生成には必ずCSPRNG（言語・OS標準の暗号用APIなど）を使用すべきです。

正解例： 一般的なPRNGを使用し、かつシードが予測可能な値だったため、内部状態が推測されトークンが予測可能となった。

解説： 根本原因は2点の複合です。第一に、トークン生成に暗号論的安全性を持たないPRNG（Math.random()等）を用いたこと。このPRNGは統計的な均一性はあっても、内部状態（シード）が分かれば出力列全体を再現できるアルゴリズムであり、CSPRNGが備えるべき「予測不可能性」の要件を満たしません。第二に、シード値としてサーバ起動時刻という低エントロピーかつ外部から推測可能な値を用いたこと。攻撃者はHTTPヘッダ等の副次的な情報からシード候補を絞り込めたため、総当たりでシードを特定でき、結果としてリセットトークンという「秘密であるべき値」が予測可能になってしまいました。

採点基準（12点）：

• 「暗号論的に安全でないPRNGを使用した」（6点）
• 「シード（起動時刻）が予測可能な低エントロピー値だった」（6点）

正解例： ①トークン生成にはOS/言語標準のCSPRNG（例：crypto.randomBytes()）を用いる。②トークンに十分なビット長（128ビット以上）とサーバ側での有効期限・一度きりの利用制限を設ける。

解説： 再発防止策の第一は、トークン生成のアルゴリズムそのものをCSPRNGに置き換えることです。Node.jsであればcrypto.randomBytes()、Javaであればjava.security.SecureRandom、Pythonであればsecretsモジュールなど、各言語・プラットフォームが提供する暗号論的に安全な乱数APIを利用することで、内部状態の推測によるトークン予測を防止できます。第二に、トークン自体の設計として、十分なビット長（一般に128ビット以上）を持たせて総当たり攻撃を計算量的に不可能にすることに加え、有効期限（例えば発行から15分以内）の設定や、一度使用されたトークンを即座に無効化する（使い回し防止）といった多層的な対策を組み合わせることが重要です。これらはOWASPのパスワードリセットに関するベストプラクティスとしても推奨されています。

採点基準（14点）：

• 「CSPRNG（暗号論的に安全な乱数生成API）への置き換え」を具体例とともに説明（8点）
• 「十分なビット長」「有効期限・使い捨て運用」等の補完的対策（6点）