Увеличить энтропию системы (необходимо сгенерировать ключи SSH на встраиваемом решении)

[IMB]

Доброго дня!
Есть встраиваемое решение с удалённым доступом с использованием SSH, используется dropbear.
Проблема в том, что при первом старте системы не хватает энтропии для генерации ключей сервера, да и в будущем ей особено не откуда взяться, так как устройство полностью автономно, доступ только через сеть или по RS232. Использовать заранее сгенерированные ключи не очень хочется.
Возможно ли неким образом быстро, менее чем за минуту, увеличить энтропию системы до достаточного для генерации ключей уровня?
Спасибо.

Upd:
Возможными решениями могут быть PRNGD(http://prngd.sourceforge.net/) или EGD(http://egd.sourceforge.net/), но это будет использоваться однократно.

[/dev/random]

Доброго дня!
Есть встраиваемое решение с удалённым доступом с использованием SSH, используется dropbear.
Проблема в том, что при первом старте системы не хватает энтропии для генерации ключей сервера, да и в будущем ей особено не откуда взяться, так как устройство полностью автономно, доступ только через сеть или по RS232. Использовать заранее сгенерированные ключи не очень хочется.
Возможно ли неким образом быстро, менее чем за минуту, увеличить энтропию системы до достаточного для генерации ключей уровня?
Спасибо.

Upd:
Возможными решениями могут быть PRNGD(http://prngd.sourceforge.net/) или EGD(http://egd.sourceforge.net/), но это будет использоваться однократно.

Даже полного объёма энтропийного пула обычно недостаточно для генерации ключа. Поэтому энтропия должна "поставляться" на протяжении всего процесса генерации. Для этого есть 2 подхода.
1. Использование специальных демонов или устройств (два примера таких демонов вы привели сами).
2. Активное и хаотичное использование устройств ввода-вывода. Если система встраиваемая, единственным таким устройством является сеть. Т.е. нужно гнать через сетевую карту как можно более случайные данные.

i	Уведомление от модератора /dev/random
	Тема переносится из "Работы в командной строке" в "Администрирование".

[IMB]

1. Использование специальных демонов или устройств (два примера таких демонов вы привели сами).

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

2. Активное и хаотичное использование устройств ввода-вывода. Если система встраиваемая, единственным таким устройством является сеть. Т.е. нужно гнать через сетевую карту как можно более случайные данные.

Сеть там будет использоваться очень активно, но пока энтропия "наработается" может пройти значительно время, а удалённый доступ хотелось бы иметь как можно быстрее.

Вот из этих соображений я и подумал - может быть можно скриптом увеличить энтропию?
Но если нет, то пожалую останавлюсь на варианте с заранее сгенерированными ключами.

[IMB]

А позвольте ещё вопрос - требуется SSH генератор случайных чисел при работе?
Вопрос возник потому, что даже при наличии сгенерированных ключей демон не запускается, при выводе ошибок в stderr я наблюдаю следующее:

Код: Выделить всё

# dropbear -Em
[101] Jan 01 00:00:59 Warning: Reading the random source seems to have blocked.
If you experience problems, you probably need to find a better entropy source.

Этот вывод как то наводит на мысль, что и при работе достаточно активно используется генератор случайных чисел.

[/dev/random]

А позвольте ещё вопрос - требуется SSH генератор случайных чисел при работе?

Да.

Кстати, в dropbox можно на этапе компиляции выбрать файл /dev/urandom вместо /dev/random (он не ждёт энтропию, а генерирует псевдослучайные числа, если энтропии не хватает). Только убедитесь, что ваша система сохраняет некоторое количество случайных чисел при завершении работы и восстанавливает их при загрузке, иначе использование /dev/urandom при старте системы будет огромной дырой в безопасности.

[IMB]

Кстати, в dropbox можно на этапе компиляции выбрать файл /dev/urandom вместо /dev/random (он не ждёт энтропию, а генерирует псевдослучайные числа, если энтропии не хватает).

Похоже что именно эту разницу я и спутал, что то мне показалось, что именно /dev/random лучше ведёт себя при малом объёме энтропии и не блокирует работу системы.

Только убедитесь, что ваша система сохраняет некоторое количество случайных чисел при завершении работы и восстанавливает их при загрузке, иначе использование /dev/urandom при старте системы будет огромной дырой в безопасности.

Позвольте поинтересоваться - как это лучше реализовать? Устройство могут выключить простым выдёргиванием сетевого шнура, питание по PoE, поэтому на halt и Co я ничего навесить не могу, остаётся только cron.

[/dev/random]

Позвольте поинтересоваться - как это лучше реализовать? Устройство могут выключить простым выдёргиванием сетевого шнура, питание по PoE, поэтому на halt и Co я ничего навесить не могу, остаётся только cron.

Сохранение - чтение из /dev/urandom пары килобайт данных (dd) в файл.
Восстановление - запись содержимого этого файла в /dev/urandom (cat) и удаление этого файла.
На случай "выдёргивания шнура" обычно сохраняют данные не только при "нормальном" выключении, но и сразу после восстановления (это уже будут несколько другие данные, не те, которые были только что восстановлены). Если "нормальное" выключение не предусмотрено вообще, то можно дополнительно производить сохранение по крону, скажем, раз в час.

[IMB]

Если "нормальное" выключение не предусмотрено вообще, то можно дополнительно производить сохранение по крону, скажем, раз в час.

Предусмотрено, но никто этого делать не будет

[taaroa]

Даже полного объёма энтропийного пула обычно недостаточно для генерации ключа. Поэтому энтропия должна "поставляться" на протяжении всего процесса генерации.

С Вашего позволения, поправка:
...для обхода этой проблемы используют специальный patch (CONFIG_GRKERNSEC_RANDNET, the entropy pools used for many features of Linux and grsecurity will be doubled in size).
Минусы подобного подхода: linux-only, необходимо накладывать patch на ядро.