Пожалуй всем пользователям Linux  известны такие файлы псевдо-устройств как /dev/random и /dev/urandom. Эти устройства являются интерфейсом к генератору случайных чисел ядра(RNG, random number generator).

Случайные числа(они же — непредсказуемый набор битов) очень важны в криптографии. Они являются базовыми кирпичиками для криптографических протоколов. От качества (неповторимости, непредсказуемости) этих чисел зависит стойкость всевозможных TLS-сертификатов, SSH и GPG ключей, сессионных симметричных TLS-ключей и т.д. Так же случайные числа являются основой для генерации UUID’ов, PID’ов, TCP sequence numbers и многого другого.

RNG генерит случайные числа  на основе данных из пула энтропии(entropy pool) в ядре Linux. Наполнением этого пула так же занимается RNG и делается это на основе случайных событий в системе таких как: тайминги клавиатуры и дисков, движения мыши, прерывания(interrupts), сетевой трафик.

Пул энтропии имеет фиксированный объем 4096 bits:

cat /proc/sys/kernel/random/poolsize_x000D_
4096

Размер пула нельзя изменить, это захардкожено в ядре.

Посмотреть текущий объем данных в пуле:

cat /proc/sys/kernel/random/entropy_avail_x000D_
186

Доступный объем энтропии постоянно меняется, в зависимости от скорости пополнения и потребления соответственно.

Собственно через /dev/random и /dev/urandom приложения в user space получают эти самые случайные числаданные.

/dev/random является источником случайных данных наивысшего качества которые может предоставить ядро. Но при этом он блокирующийся, что означает, что приложение читающее из /dev/random повиснет в ожидании данных если пул энтропии окажется пустым.

/dev/urandom  — unlimited random, не блокирующийся и приложения могут читать из него бесконечно. Предоставляет случайные данные такого же высокого качества что и /dev/random но до тех пор пока пул энтропии не опустеет. Когда пул будет пустым, /dev/urandom продолжит выдавать случайные данные но теоретически сильно меньшего качества.

Настоятельно рекомендуется для любых долго-живущих ключей, например для TLS-сертификатов использовать /dev/random т.к. только он гарантирует качество случайных чисел. Но, большинство приложений таких как Apache, Nginx, sshd и о Боже ssh-keygen, openssl используют /dev/urandom. Тут в принципе понятно Apache, Nginx, sshd не хотят блокироваться при генерации сессионных ключей. Но то, что ssh-keygen и openssl используют по умолчанию /dev/urandom меня поразило. Причем для openssl можно задать устройство при генерации ключей(ниже пример) а вот для ssh-keygen я возможности переопределить поведение не нашел.

В общем не важно откуда читают ваши приложения, нельзя допускать опустошение этого самого пула энтропии и тогда счастье будет и с /dev/urandom.

Прежде чем начать “майнить” энтропию, пара слов о ее корректном использовании из man /dev/random:

The amount of seed material required to generate a cryptographic key equals the effective key size of the key. For example, a 3072-bit RSA or Diffie-Hellman private key has an effective key size of 128 bits (it requires about 2^128 operations to break) so a key generator only needs 128 bits (16 bytes) of seed material from /dev/random.

Например openssl для генерации RSA ключа длиной 10240 bit использует всего 2048 исходного материала из /dev/random:

strace -e open openssl genrsa -rand /dev/random -out rootCA.key 10240_x000D_
…._x000D_
open("/dev/random", O_RDONLY)           = 4_x000D_
2048 semi-random bytes loaded_x000D_
Generating RSA private key, 10240 bit long modulus

Как заполнить пул энтропии?

Лучшее решение это использование специальных аппаратных средств(TPM, Trusted Platform Module) или инструкций процессора типа RDRAND(есть в Intel IvyBridge и Haswell процессорах).

Проверить наличие подобных устройств на сервере поможет утилита rngd из пакета rng-tools

rngd -v_x000D_
Unable to open file: /dev/tpm0_x000D_
can't open any entropy source_x000D_
Maybe RNG device modules are not loaded

Если rngd обнаружит поддерживаемые средства то вам повезло и вы можете запустить сервис rngd. В моем случае их нет)

Собственно задача rngd читать энтропию из аппаратных средств и наполнять ей пул энтропии ядра. Делается это через специальный ioctl вызов(RNDADDENTROPY) интерфейса /dev/random.

Если нет аппаратной поддержки

В интернете можно встретить рекомендации, где предлагают указывать /dev/urandom как источник энтропии для rngd. То есть источником энтропии для ядра по сути будет само ядро). Это довольно сомнительная идея, и я бы не стал так делать и вам не советую. Но ради эксперимента я провел тесты и результаты(которые ниже) тоже довольно не плохие.

Havegd

В основе лежит алгоритм HAVAGE который генерирует энтропию на основе счётчиков и состояний процессора. В силу сложного, многоуровневого устройства процессоров, один и тот же код всегда выполняется за разное время и это не постоянство является основой для алгоритма HAVAGE.

На практике, это user space демон который как и rngd наполняет пул энтропии ядра через ioctl интерфейс /dev/random. при этом не нуждается в источнике энтропии как rngd.

Для centos пакет доступен из epel.

После установки нужно просто запустить сервис. С параметрами по умолчанию haveged будет стараться держать пул энтропии ядра на уровне не ниже 1024.

Тестирование

Без rngd и haveged, команда(ниже будет понятно, что она делает):

cat /dev/random | rngtest -c 10000

Не завершилась за сутки!

rngd с /dev/urandom в качестве источника энтропии

(то, что я вам не рекомендовал)

Unit-файл rngd.service:

[Unit]_x000D_
Description=Hardware RNG Entropy Gatherer Daemon_x000D_
[Service]_x000D_
ExecStart=/sbin/rngd -f -r /dev/urandom -o /dev/random_x000D_
[Install]_x000D_
WantedBy=multi-user.target

Тест(худший из 3-х результат):

cat /dev/random | rngtest -c 10000_x000D_
_x000D_
rngtest 5_x000D_
Copyright (c) 2004 by Henrique de Moraes Holschuh_x000D_
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE._x000D_
rngtest: starting FIPS tests..._x000D_
rngtest: bits received from input: 200000032_x000D_
rngtest: FIPS 140-2 successes: 9989_x000D_
rngtest: FIPS 140-2 failures: 11_x000D_
rngtest: FIPS 140-2(2001-10-10) Monobit: 0_x000D_
rngtest: FIPS 140-2(2001-10-10) Poker: 2_x000D_
rngtest: FIPS 140-2(2001-10-10) Runs: 6_x000D_
rngtest: FIPS 140-2(2001-10-10) Long run: 3_x000D_
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0_x000D_
rngtest: input channel speed: (min=3.234; avg=7.202; max=7.981)Mibits/s_x000D_
rngtest: FIPS tests speed: (min=90.826; avg=142.151; max=146.719)Mibits/s_x000D_
rngtest: Program run time: 27833279 microseconds

Тут нужно смотреть на successes, failures, и на input channel speed.

При этом утилизация CPU процессом rngd: 57%

haveged

Тест(худший из 3-х результат):

cat /dev/random | rngtest -c 10000_x000D_
_x000D_
rngtest 5_x000D_
Copyright (c) 2004 by Henrique de Moraes Holschuh_x000D_
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE._x000D_
rngtest: starting FIPS tests..._x000D_
rngtest: bits received from input: 200000032_x000D_
rngtest: FIPS 140-2 successes: 9993_x000D_
rngtest: FIPS 140-2 failures: 7_x000D_
rngtest: FIPS 140-2(2001-10-10) Monobit: 1_x000D_
rngtest: FIPS 140-2(2001-10-10) Poker: 0_x000D_
rngtest: FIPS 140-2(2001-10-10) Runs: 4_x000D_
rngtest: FIPS 140-2(2001-10-10) Long run: 2_x000D_
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0_x000D_
rngtest: input channel speed: (min=1.780; avg=15.692; max=18.755)Mibits/s_x000D_
rngtest: FIPS tests speed: (min=79.473; avg=143.212; max=150.185)Mibits/s_x000D_
rngtest: Program run time: 13493892 microseconds

При этом утилизация CPU процессом haveged:12%

Виртуальные машины

Не рекомендуется использовать haveged внутри ВМ, т.к. там  вроде как счетчики CPU не такие точные(типа округляются) и это сказывается на качестве энтропии.
Тру путь это использовать virt-ioRNG(qemu-kvm) — паравиртуальное устройство которое будет брать энтропию из пула хоста. Но, это уже совсем другая история…)

Помогла ли вам статья?