Linux: ロック プール /dev/random の削除

/dev/random は暗号的に安全な擬似乱数生成器 (CSPRNG) であり、ブロッキングという厄介な問題があることが知られています。 この記事では、それを解決する方法について説明します。

過去数か月にわたって、カーネル内の乱数生成機能はわずかに作り直されましたが、このサブシステムの問題は、より広範な開発期間を通じて解決されました。 時間枠. 多くの 最後の変更 これは、システムの起動時に getrandom() システム コールが長時間ブロックされるのを防ぐために作成されましたが、その根本的な理由はランダム プールのブロック動作でした。 最近のパッチではこのプールが削除され、メイン コアに向かうことが予想されていました。

Andy Luomirski は XNUMX 月末にパッチの XNUMX 番目のバージョンを公開しました。 彼は貢献します 「ランダムな Linux API に対する XNUMX つの主要なセマンティック変更」。 このパッチは、getrandom() システム コールに新しい GRND_INSECURE フラグを追加します (ただし、Lutamirsky はこれを getentropy() と呼んでいますが、これは固定フラグ付きの getrandom() を使用して glibc に実装されています)。 このフラグにより​​、呼び出しは常に要求されたデータ量を返しますが、データがランダムであることは保証されません。 カーネルは、その時点で最良のランダム データを生成するために最善を尽くします。 「おそらく最善の方法は、それを「不安」と呼ぶことです (安全ではありません) この API がセキュリティを必要とするものに使用されるのを防ぎます。」

このパッチはブロッキング プールも削除します。 カーネルは現在 XNUMX つのランダム データ プールを維持しています。XNUMX つは /dev/random に対応し、もう XNUMX つは /dev/urandom に対応します。これについては、この記事で説明しています。 статье 2015年。 ブロッキング プールは /dev/random のプールです。 リクエストを満たすのに「十分な」エントロピーがシステムから収集されるまで、そのデバイスの読み取りは (その名前を意味する) ブロックされます。 プールに十分なエントロピーがない場合、このファイルからのさらなる読み取りもブロックされます。

ロック プールを削除するということは、/dev/random からの読み取りがフラグを 0 に設定した getrandom() のように動作することを意味します (そして、GRND_RANDOM フラグが noop に変わります)。 暗号化乱数ジェネレーター (CRNG) が初期化されると、/dev/random からの読み取りと getrandom(...,XNUMX) の呼び出しはブロックされず、要求された量のランダム データが返されます。

ルトミルスキーは次のように述べています。 「Linux ブロッキング プールは時代遅れになったと思います。 CRNG Linux は、鍵の生成にも使用できる十分な出力を生成します。 ブロッキングプールは物質的な意味で強力ではなく、それをサポートするには価値が疑わしい多くのインフラストラクチャを必要とします。」

この変更は、既存のプログラムが実際には影響を受けないようにすることを目的として行われ、実際、GnuPG キーの生成などで長い待ち時間が発生する問題が少なくなります。

「これらのエピソードは既存の番組を混乱させてはなりません。 /dev/urandom は変更されません。 /dev/random は依然として起動直後にブロックしますが、以前よりもブロック数は減りました。 既存のフラグを使用した getentropy() は、以前と同様に実用的な目的に適した結果を返します。」

ルトミルスキー氏は、カーネルがいわゆる「真の乱数」を提供すべきかどうかはまだ未解決の問題であり、これはブロッキングカーネルがある程度行うべきことであると指摘した。 彼はその理由をただ XNUMX つ、「政府の基準への準拠」だと考えています。 ルトミルスキー氏は、カーネルがこれを提供する場合、完全に異なるインターフェイスを通じて実行するか、ユーザー空間に移動して、ユーザーがそのようなロック プールの作成に使用できる生のイベント サンプルを取得できるようにする必要があると提案しました。

ステファン・ミュラーは彼のセットを提案しました パッチ Linux 用の乱数ジェネレーター (LRNG) (現在バージョン 26 がリリースされています) は、それを必要とするアプリケーションに真の乱数を提供する方法になる可能性があります。 LRNG は「ランダム ビットの生成に使用されるエントロピー ソースに関する SP800-90B ガイドラインに完全に準拠」しており、政府の標準の問題に対する解決策となります。
Matthew Garrett 氏は、「真のランダム データ」という用語に反対し、サンプリングされたデバイスは原理的には予測可能になるほど正確にモデル化できると指摘し、「ここでは量子イベントをサンプリングしているわけではありません」と述べました。

ミュラー氏は、この用語は「基礎となるノイズ源がエントロピーを生成するのと同じレートで」結果のみを生成する乱数発生器を表すドイツの標準AIS 31に由来すると答えた。

用語の違いはさておき、LRNG パッチで提案されているロック プールを使用すると、少なくとも特権なしでアクセスした場合には、単純にさまざまな問題が発生します。

ルトミルスキーはこう言った。 「これでは問題は解決しません。 XNUMX 人の異なるユーザーが gnupg のような愚かなプログラムを実行すると、お互いに消耗するだけです。 現在、/dev/random には XNUMX つの主な問題があることがわかりました。XNUMX つは DoS (つまり、リソースの枯渇、悪意のある影響など) の危険性があり、もう XNUMX つは、/dev/random を使用するのに特権が必要ないため、悪用されやすいということです。 Gnupg は間違っています。完全に崩壊しています。 gnupg や同様のプログラムが使用する新しい非特権インターフェイスを追加すると、再び負けることになります。」

Mueller 氏は、getrandom() の追加により、プールが初期化されていることの必要な保証が提供されるため、GnuPG がこのインターフェースを使用できるようになると述べました。 GnuPG 開発者 Werner Koch との議論に基づいて、Mueller 氏は、GnuPG が現在 /dev/random から直接読み取る唯一の理由はこの保証であると考えています。 しかし、サービス拒否の影響を受けやすい特権のないインターフェイスが存在する場合 (今日の /dev/random のように)、それは一部のアプリケーションによって悪用されるだろうと Luomirsky 氏は主張します。

Linux の乱数サブシステムの開発者である Theodore Yue Tak Ts'o 氏は、ブロッキング プールの必要性について考えを変えたようです。 同氏は、このプールを削除することで、Linux に真の乱数生成器 (TRNG) があるという考えを効果的に取り除くことができると述べました。 「これはナンセンスではありません。これはまさに *BSD が常に行ってきたことだからです。」

同氏はまた、TRNG メカニズムの提供がアプリケーション開発者にとって単なるおとりになるのではないかと懸念しており、実際、Linux がサポートするさまざまな種類のハードウェアを考慮すると、カーネル内で TRNG を保証することは不可能であると考えています。 root 権限だけで機器を操作できるようにしても、問題は解決されません。 「アプリケーション開発者は、セキュリティ上の理由から、アプリケーションを root としてインストールするように指定しています。そのため、これが『本当に適切な』乱数にアクセスできる唯一の方法です。」

モラー氏は、曹氏自身が長年提案してきたブロッキングプールの導入を放棄したかどうかを尋ねた。 Cao氏は、Lutomirsky氏のパッチを採用するつもりであり、ブロッキングインターフェイスをカーネルに戻すことには積極的に反対すると答えた。

「カーネルは、ノイズ源が適切に特徴づけられているかどうかについては保証できません。 GPG や OpenSSL の開発者が得られるのは、TRUERANDOM の方が「優れている」という漠然とした感覚だけであり、セキュリティをさらに強化したいため、間違いなくそれを使用しようとするでしょう。 ある時点でそれはブロックされ、他の賢明なユーザー (おそらく配布専門家) がそれを init スクリプトに挿入してシステムが動作しなくなった場合、ユーザーは Linus Torvalds 本人に苦情を言うだけで済みます。」

Cao 氏はまた、暗号学者や実際に TRNG を必要とする人々に、ユーザー空間で独自のエントロピーを収集して必要に応じて使用できる方法を提供することを提唱しています。 同氏は、エントロピーの収集は、カーネルがサポートするさまざまなハードウェアすべてで実行できるプロセスではなく、カーネル自体がさまざまなソースから提供されるエントロピーの量を推定することもできないと述べています。

「カーネルは異なるノイズソースを混合すべきではありません。また、非常に単純な CPU 上である種の「神経質なエントロピー ゲーム」をプレイしようとするときに、何ビットのエントロピーを取得しているかを知ろうとするべきではありません。 「コンシューマ ユーザー向けのアーキテクチャ。単一のマスター オシレータとすべてが同期していない、レジスタの並べ替えや名前変更を行う CPU 命令がない IOT/組み込みのケースなど」

「これらの計算を行うツールを提供することについて話すことはできますが、そのようなことは各ユーザーのハードウェア上で実行する必要があり、これはほとんどのディストリビューション ユーザーにとって現実的ではありません。 これが暗号作成者のみを対象としている場合は、暗号作成者のユーザー空間で実行させてください。 また、GPG や OpenSSL などを単純化して、誰もが「『真のランダム性』が必要で、それ以下では妥協しない」と言うのはやめましょう。 分離され名前が付けられた一次ノイズ源にアクセスして必要な情報を取得できるように、暗号作成者にインターフェイスを提供する方法について話し合うことができます。また、おそらく何らかの方法でノイズ源がライブラリまたはユーザー空間アプリケーションに対して自身を認証できる可能性があります。」

たとえば、一部のイベントにはセキュリティへの影響がある可能性があるため、そのようなインターフェイスがどのようなものになるかについて議論がありました。 Cao氏は、キーボードのスキャンコード（つまりキーストローク）がエントロピー収集の一環としてプールに混合されることを指摘し、「特権システムコールを介したとしても、これをユーザー空間に持ち込むのは、控えめに言っても賢明ではない」と述べた。 他のイベントのタイミングによって、サイドチャネルを通じて何らかの情報漏洩が発生する可能性は十分にあります。

つまり、Linux の乱数サブシステムに関する長年の問題は解決に向かいつつあるようです。 最近乱数サブシステムに加えられた変更は、実際には、乱数サブシステムの使用中に DoS 問題を引き起こすだけでした。 カーネルが提供できる最良の乱数を取得する効率的な方法が登場しました。 Linux 上で TRNG が依然として望ましい場合、この欠陥は将来的に対処する必要がありますが、おそらくカーネル自体内でこれが行われることはありません。

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com