Ох энтро́пии мне мало... ветер пью, туман глотаю

[vak]

Почему NetBSD часто тормозит на i486 процессоре? Выяснились две причины: шифрование свопа и нехватка энтропии.

Не знаю, кто придумал включить по умолчанию шифрование страниц, откачиваемых в своп. Без аппаратной поддержки шифрования это убивает производительность напрочь. Отключается легко: достаточно добавить строчку "vm.swap_encrypt=0" в файл /etc/sysctl.conf.

С энтропией ситуация сложнее. При загрузке ядро NetBSD выдает строчку, означающую, что дело плохо.

WARNING: system needs entropy for security; see entropy(7)

За последние 10 лет мы привыкли к защищённым протоколам типа HTTPS и SSH, и не интересуемся деталями. А им для работы нужен качественный источник случайности. Иначе протокол станет слишком предсказуемым, а значит хакеры могут взломать его, легко подобрав ключ.

Когда вы подключаетесь к веб-сайту через HTTPS, ваш браузер и сервер выполняют «рукопожатие», чтобы согласовать секретный ключ шифрования. Если этот ключ генерируется с использованием низкой энтропии (предсказуемые данные), хакеру не нужно «взламывать» шифрование; ему достаточно угадать ключ. Стандартный 128-битный ключ имеет много возможных комбинаций. Если ваша система обладает высокой энтропией, хакеру придется перебрать почти все из них (что займет миллиарды лет). Если ваша энтропия низкая, ему, возможно, потребуется перебрать всего несколько тысяч.

В процессе передачи с каждым сообщением отправляется дополнительная случайная строка, чтобы гарантировать, что даже если вы отправите одну и ту же команду дважды (например, «Заплатить 10 долларов»), зашифрованные данные будут выглядеть совершенно по-разному каждый раз. Без высокой энтропии эти одноразовые числа могут повторяться или следовать определенному шаблону. Злоумышленник может записать старое зашифрованное сообщение и «воспроизвести» его позже, чтобы обмануть сервер.

Откуда протокол берёт эту энтропию? В ядре операционной системы имеется специальный буфер, где хранится некоторый запас, обычно несколько тысяч качественных случайных бит. Установление каждого нового HTTPS-соединения потребляет примерно от 256 до 512 бит (от 32 до 64 байт) из этого запаса, то есть порядка 10%. На каждый передаваемый пакет тоже нужно немного случайности, но там уже работает псевдослучайный генератор. В активных системах (особенно на серверах или небольших устройствах IoT) запас энтропии может опустеть, если нужно быстро сгенерировать слишком много ключей. Система может замереть и ждать, пока не будет собрано больше случайных данных. Источником служит или специальный аппаратный генератор шума (TRNG), встроенный в современный процессор, или драйверы некоторых периферийных устройств. Скажем, можно отслеживать микроизменения времени, необходимого жесткому диску для поиска данных.

Мы не замечаем проблемы энтропии, потому что на современных устройствах генераторы шума встроены в процессор. На древнем же компьютере ничего такого нет, и поэтому вход по SSH на мой Cx486 занимает 78 секунд. Время уходит на сбор энтропии и генерацию одноразового ключа для защищённого сеанса.

Энтропию в ядро можно легко добавлять, просто записывая случайные данные в /dev/urandom. Вопрос, откуда брать качественную случайность. Скажем, можно соорудить девайс на микроконтроллере RP2350 и подключить его на COM порт. В этом чипе есть блок TRNG, способный выдавать 7500 случайных бит в секунду. Это примерно 938 байт/сек. Хватит с запасом на все потребности.

Comments

[dimorlus]

Мне кажется, из какого-нибудь game port можно довольно просто и чисто аналоговыми методами получить случайные данные

[vak]

Из любого АЦП можно, но получается мало и плохого качества.

Народ что только не пристраивает в качестве источника энтропии. Стену из лавовых ламп, к примеру.

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

https://blog.cloudflare.com/lavarand-in-production-the-nitty-gritty-technical-details/

[dimorlus]

Есть же простые схемы, генерирующие хаотичные "полноразмерные", на весь диапазон АЦП сигналы, на паре ОУ делаются, или даже проще, подключенные к X-Y входам осциллоскопа они завораживающие картинки рисуют, не хуже тех лавовых ламп (но намного проще в реализации). Что интересно, они и в симуляторах также работают. Неужели оцифровка таких сигналов не дает достаточно случайной последовательности бит, особенно если их потом еще перемешать?

[vak]

Выходит слишком высокая корреляция оцифрованного сигнала с предыдущим значением.

[dimorlus]

А кто и как это проверяет?

[tiresome_cat]

Интересно.

[kondybas]

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

В середньому тільки половину.

[vak]

Половина від 2¹²⁸ все ж таки 2¹²⁷. Немало. 😀

[x86128]

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

[itsi]

Интернет для этого использовать.

[fenikso]

О! Ходить в Интернет за случайньіми числами! :)

[brumka]

Отличный ликбез, спасибо. Я вот не знал, что генераторы случайных чисел встраиваются в современные процессоры. То есть очень логично, но я думал, что всякие rand() выполняются исключительно программно. Надо-бы, при случае, полюбопытствовать как это реализовано, например, в HSM модулях

[sassa_nf]

> rand()

It depends.

Intel has RDRAND, which ends up in /dev/random. But a lot of software uses /dev/urandom, as that is a PRNG, so is not blocking.

[brumka]

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

[prool]

Студент! Возьми ведро сходи в сад накопай энтропии