Tomcat занимает слишком много времени, чтобы начать - Java SecureRandom

Не помещайте его как дубликат. Это следующий вопрос для обоих этих вопросов.

Я понимаю, что

заменяет файл securerandom.source =/dev/urandom с securerandom.source = файл:/dev/./urandom в $JAVA_PATH/JRE/Library/безопасность/java.security

решит эту проблему. Мой вопрос в том, хорошо ли это делать на производстве? Будет ли это иметь какое-либо влияние на безопасность (например, идентификатор сеанса становится предсказуемым)? Если это менее безопасно, есть ли другой способ быстрее получить энтропию?

Update

Я использую openstack для развертывания (или просто говорю, использует AWS или GCP или любой другой поставщик облачных вычислений). Таким образом, добавление аппаратного устройства, такого как звуковая карта, не является для меня вариантом.

Ответ 1

После некоторого обширного Googling с правильными условиями поиска я наткнулся на эту приятную статью на DigitalOcean. Я просто цитирую соответствующую часть здесь.

В Linux есть два обычных случайных устройства:/dev/random и /DEV/urandom. Лучшая случайность возникает из /dev/random, так как она блокирующего устройства и будет ждать достаточной энтропии для продолжения предоставления продукции. Предполагая, что вашей энтропии достаточно, вы должен видеть то же качество случайности от /dev/urandom; Однако, поскольку это неблокирующее устройство, оно будет продолжать создавать "случайные", данных, даже когда заканчивается энтропийный пул. Это может привести к снижению качественные случайные данные, поскольку повторения предыдущих данных гораздо более вероятны. Множество плохих вещей может произойти, когда доступная энтропия работает на производственный сервер, особенно когда этот сервер выполняет криптографическую функции.

Таким образом, это потенциальный риск для безопасности.

Решение для заполнения энтропийных пулов

Linux уже получает очень качественные случайные данные из разные аппаратные источники, но поскольку обычно безглазная машина не имеет клавиатуры или мыши, создается гораздо меньше энтропии. диск и сетевой ввод-вывод представляют собой большинство источников генерации энтропии для этих машин, и они производят очень редкие количества энтропии. Поскольку очень немногие безголовые машины, такие как серверы или облачные серверы/виртуальные машины имеют какое-то специальное аппаратное решение RNG, существует несколько пользовательских решений для генерации дополнительной энтропии используя аппаратные прерывания от устройств, которые являются "более шумными", чем жесткие дисков, таких как видеокарты, звуковые карты и т.д. Это еще раз доказывает к сожалению, проблема для серверов, поскольку они обычно не содержат либо один

Решение: hasged

Основываясь на принципе HAVEGE и ранее на основе его ассоциированных библиотеки, позволяет создавать случайность на основе изменений в время выполнения кода на процессоре. Поскольку это почти невозможно для один кусок кода, чтобы выполнить то же точное время для выполнения, даже в та же среда на одном и том же оборудовании, время запуска одного или несколько программ должны быть пригодны для посева случайного источника. вытеснили семена внедрения, ваш системный случайный источник (обычно /dev/random ), используя различия в счетчике метки времени процессора (TSC) после повторения цикла

Как установить hasged

Выполните действия, описанные в этой статье. https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Ответ 2

Afaik,/dev/urandom поддерживает несколько hw-реализаций через ядро linux.

https://en.wikipedia.org/wiki/Hardware_random_number_generator

Итак, если вы находитесь на сервере, без поддержки производительности hw, возможно, сильно пострадали.

рассматривает

Николай Хансен