Rng-tools

関連記事

• Haveged
• Trusted Platform Module
• 乱数生成

ノート: rng-tools は Kernel 5.6 以降、/dev/random がブロックしなくなったので不要になりました [1]

rng-tools はカーネルの乱数生成に関するユーティリティのセットです。メインのプログラムは rngd で、ハードウェアデバイスからカーネルのエントロピープールにランダムなデータを入力するために開発されたデーモンになります。

rng-tools は主にカーネルのエントロピーを増やして /dev/random を高速するために使われます。デフォルトでは、/dev/random はデバイスドライバなどの (遅い) ソースからしかエントロピーを収集しないため、極めて遅くなっています。rngd は高速なエントロピーソースを利用することが可能です。最新の AMD/Intel プロセッサ, Via Nano, あるいは Raspberry Pi などの新しいハードウェアに搭載されているハードウェア乱数生成器 (TRNG) を主に利用します。

Linux 自体も TRNG からの情報を /dev/random に活かすようにしていますが、あくまで カーネルが収集したエントロピーの XOR にしか使われていません。そのため、たとえ TRNG が搭載されていても、デフォルトでは /dev/random はかなり低速です。rngd は利用可能なエントロピーを大幅に増やして /dev/random に流し込みます。

インストール

rng-tools パッケージをインストールしてください。

設定

設定ファイルは /etc/conf.d/rngd です。ただしオプションは RNGD_OPTS しかありません。付属している systemd サービス (rngd.service) でデーモンを起動したときに RNGD_OPTS のパラメータが渡されます。大抵の場合はデフォルトのパラメータ ("" つまり空白) で問題ありません。

デフォルトで、rngd は TRNG を自動的に検出して使用します。rng-tools の最新版で Raspberry Pi や Intel Ivy Bridge CPU の自動検出が機能することが報告されています。自動で検出されない場合、手動で TRNG が使用するデバイスファイルを指定することができます。例:

RNGD_OPTS="-o /dev/random -r /dev/my_hw_random_device"

警告: インターネット上にある文章や、あるいは rng-tools の古いバージョンでは、TRNG を搭載していないシステムでは以下の行を使うことが推奨されていることがあります:

RNGD_OPTS="-o /dev/random -r /dev/urandom"

当たり前ですが、上記は 本当に悪い考え です。カーネルのエントロピープールを満杯にするのに、そのカーネルのエントロピーを使うのは馬鹿げています。あなたの使っているコンピュータに TRNG が搭載されていないのであれば haveged を使ってください。詳しくは FS#34580 を参照。

コンピュータに TPM モジュールが載っていない場合は、RNGD_OPTS に "--no-tpm=1" を指定することで、ログに以下の警告メッセージが表示されないようにすることができます:

Unable to open file: /dev/tpm0

デフォルトでは rngd はエントロピープールに2048バイトまでしかエントロピーを貯めません。プールの中身が TRNG だけになるのを防ぐためです。TRNG から弾き出される値が絶対にランダムだと信用できるというのであれば、この設定は上書きすることが可能です。RNGD_OPTS に "--fill-watermark=4096" などと指定してください (デフォルトでは4096がカーネルのエントロピープールの最大サイズです。最大値より大きい値は指定しないでください)。TRNG を使用する割合を高めることで /dev/random のパフォーマンスはさらに上がりますが、乱数の品質が低くなるかもしれません。普通の使い方であれば、デフォルト設定で十分です。

テストと使い方

サービスを有効にする前に、以下のコマンドを実行することで rngd が動作するかどうかテストできます:

# rngd -f

(rngd が動作しているのとは別のターミナルで) 以下のコマンドを使えば簡単な乱数生成のテストが可能です:

$ dd if=/dev/random of=/dev/null bs=1024 count=1 iflag=fullblock

rngd を使わなかった場合、上記のコマンドの実行には長い時間がかかることになるでしょう。rngd が正しく動作していれば、あっという間に実行が完了するはずです:

1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.0199623 s, 51.3 kB/s

dd の出力が 50 kB/s ほどの速度を出していれば問題ありません。比較として、rngd を使わなかった場合 (速度があまりにも遅くて) 0.0 kB/s になるでしょう。

また、rngtest を実行することで、FIPS 140-2 テストを使ってランダム性をチェックすることもできます:

$ rngtest -c 1000 </dev/random

rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 999
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 1
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=301.394; avg=417.091; max=693.187)Kibits/s
rngtest: FIPS tests speed: (min=64.656; avg=91.010; max=123.055)Mibits/s
rngtest: Program run time: 47037492 microseconds

どんな乱数生成器でも1000個のテストで少しばかり通らないことがあるのは普通です。ただし failures の数があまりに大きい場合 (10以上など)、何かがおかしいと思ってください。

テストが終わったら、rngd.service を起動・有効化してください。

散発的に CPU が 100% にスパイクする

最近の Raspberry Pi のいくつかのモデル (3B+と4B) および ODROID-C1 で文書化されている一部のハードウェアでは、すべてのコアで 100% に達する散発的な CPU スパイクが発生することがあります。このスパイクは数時間または数日続く場合があります。 Issue#136 を参照してください。アップストリーム修正がマージされるまでこれを修正するには、/etc/conf.d/rngd を編集して次のオプションを含めます。

RNGD_OPTS="-x jitter -r /dev/hwrng"

その後、rngd.service を restart