В операционных системах типа Unix / dev/random и /dev/urandom — это специальные файлы , которые служат криптографически безопасными генераторами псевдослучайных чисел (CSPRNG). Они позволяют получить доступ к CSPRNG , который засеян энтропией (значением, обеспечивающим случайность ) из окружающего шума, собранного с драйверов устройств и других источников. [1] /dev/random обычно блокируется , если доступно меньше энтропии , чем запрошено; в последнее время (см. ниже различия между операционными системами) он обычно блокируется при запуске, пока не будет собрано достаточно энтропии, а затем разблокируется навсегда. Устройство /dev/urandom обычно никогда не было блокирующим устройством, даже если зародыш генератора псевдослучайных чисел не был полностью инициализирован энтропией с момента загрузки. Не все операционные системы реализуют одни и те же методы для /dev/random и /dev/urandom .
Этот специальный файл появился в Linux в 1994 году. Он был быстро принят другими Unix-подобными операционными системами. [2]
Ядро Linux предоставляет отдельные файлы устройств /dev/random и /dev/urandom . Начиная с версии ядра 5.6 2020 года, /dev/random блокируется только тогда, когда CSPRNG не инициализирован. После инициализации /dev/random и /dev/urandom ведут себя одинаково. [3]
В октябре 2016 года, с выпуском ядра Linux версии 4.8, /dev/urandom ядра был переключен на реализацию криптографического генератора псевдослучайных чисел (CPRNG) на основе ChaCha20 [4] , разработанную Теодором Цо на основе хорошо известного потокового шифра Бернштейна ChaCha20 .
Начиная с версии 5.17 ядра Linux, генератор случайных чисел перешел с использования криптографической хэш-функции SHA-1 в сборщике энтропии на BLAKE2s — более новую, быструю и безопасную хэш-функцию. [5]
Генерация случайных чисел в пространстве ядра была впервые реализована для Linux [2] в 1994 году Теодором Цо . [6] Реализация использовала безопасные хэши вместо шифров , [ необходимо разъяснение ] чтобы избежать ограничений на экспорт криптографии , которые были на момент первоначального проектирования генератора. Реализация также была разработана с предположением, что любой заданный хэш или шифр может в конечном итоге оказаться слабым, и поэтому конструкция устойчива к любым таким слабостям. Быстрое восстановление после компрометации пула не считается требованием, поскольку требования к компрометации пула достаточны для гораздо более простых и прямых атак на несвязанные части операционной системы.
В реализации Цо генератор сохраняет оценку количества бит шума в пуле энтропии . Из этого пула энтропии создаются случайные числа. При чтении устройство /dev/random будет возвращать только случайные байты в пределах предполагаемого количества бит шума в пуле энтропии. Когда пул энтропии пуст, чтение из /dev/random будет блокироваться до тех пор, пока не будет собран дополнительный шум окружающей среды. [7] Цель состоит в том, чтобы служить криптографически безопасным генератором псевдослучайных чисел , предоставляя вывод с максимально возможной энтропией. Это предлагается авторами для использования при генерации криптографических ключей для высокоценной или долгосрочной защиты. [7]
Аналогом /dev/random является /dev/urandom («неограниченный» [8] /неблокируемый случайный источник [7] ), который повторно использует внутренний пул для создания большего количества псевдослучайных битов. Это означает, что вызов не будет блокироваться, но вывод может содержать меньше энтропии, чем соответствующее чтение из /dev/random . Хотя /dev/urandom по-прежнему предназначен как генератор псевдослучайных чисел, подходящий для большинства криптографических целей, авторы соответствующей страницы руководства отмечают, что теоретически может существовать пока неопубликованная атака на алгоритм, используемый /dev/urandom , и что пользователи, обеспокоенные такой атакой, должны использовать /dev/random вместо этого. [7] Однако такая атака вряд ли произойдет, потому что как только пул энтропии станет непредсказуемым, он не будет давать утечку безопасности из-за уменьшенного количества битов. [9]
Также можно записывать в /dev/random . Это позволяет любому пользователю подмешивать случайные данные в пул. Неслучайные данные безвредны, поскольку только привилегированный пользователь может выдать ioctl, необходимый для увеличения оценки энтропии. [ dubious – обсудить ] Текущее количество энтропии и размер пула энтропии ядра Linux, оба измеренные в битах, доступны в /proc/sys/kernel/random/ и могут быть отображены командой и соответственно.cat /proc/sys/kernel/random/entropy_availcat /proc/sys/kernel/random/poolsize
Gutterman, Pinkas и Reinman в марте 2006 года опубликовали подробный криптографический анализ генератора случайных чисел Linux [10] , в котором описали несколько слабых мест. Возможно, самая серьезная проблема, о которой они сообщают, связана со встроенными или Live CD- системами, такими как маршрутизаторы и бездисковые клиенты , для которых состояние загрузки предсказуемо, а доступный запас энтропии из среды может быть ограничен. Для системы с энергонезависимой памятью они рекомендуют сохранять некоторое состояние из RNG при выключении, чтобы его можно было включить в состояние RNG при следующей перезагрузке. В случае маршрутизатора, для которого сетевой трафик представляет собой основной доступный источник энтропии, они отмечают, что сохранение состояния между перезагрузками «потребует от потенциальных злоумышленников либо прослушивания всего сетевого трафика» с момента первого ввода маршрутизатора в эксплуатацию, либо получения прямого доступа к внутреннему состоянию маршрутизатора. Эта проблема, как они отмечают, особенно критична в случае беспроводного маршрутизатора, сетевой трафик которого может быть перехвачен на расстоянии и который может использовать RNG для генерации ключей для шифрования данных.
Ядро Linux обеспечивает поддержку нескольких аппаратных генераторов случайных чисел , если они установлены. Необработанный вывод такого устройства может быть получен из /dev/hwrng . [11]
С ядром Linux 3.16 и новее [12] само ядро смешивает данные из аппаратных генераторов случайных чисел в /dev/random по скользящей шкале на основе определяемого качества оценки энтропии HWRNG. Это означает, что для выполнения этой работы не требуется демон пользовательского пространства, такой как rngd из rng-tools . С ядром Linux 3.17+ RNG VirtIO был изменен так, чтобы иметь качество по умолчанию, определенное выше 0, [13] и, как таковой, в настоящее время является единственным HWRNG, смешанным в /dev/random по умолчанию.
Энтропийный пул может быть улучшен такими программами, как timer_entropyd , haveged , randomsound и т. д. С помощью rng-tools аппаратные генераторы случайных чисел, такие как Entropy Key и т. д., могут записывать в /dev/random . Программы diehard tests diehard , dieharder и ent могут тестировать эти генераторы случайных чисел. [14] [15] [16] [17]
В январе 2014 года Дэниел Дж. Бернстайн опубликовал критику [18] того, как Linux смешивает различные источники энтропии. Он описывает атаку, в которой один источник энтропии, способный контролировать другие источники энтропии, может изменить свой вывод, чтобы свести на нет случайность других источников энтропии. Рассмотрим функцию , где H — хэш-функция, а x , y и z — источники энтропии, причем z — вывод вредоносного HRNG Z на базе ЦП:
Бернстайн подсчитал, что злоумышленнику потребуется повторить 16 раз , чтобы скомпрометировать DSA и ECDSA, сделав первые четыре бита выходного сигнала RNG равными 0. Это возможно, поскольку Linux постоянно обновляет начальное число H вместо использования одного высококачественного начального числа. [18]
Бернстайн также утверждает, что инъекция энтропии бессмысленна после инициализации CSPRNG. [18]
В ядре 5.17 (обратно портированном в ядро 5.10.119) Джейсон А. Доненфельд предложил новый дизайн инфраструктуры пула энтропии Linux. Доненфельд сообщил, что старый пул, состоящий из одного 4096-битного LFSR, уязвим для двух атак: (1) злоумышленник может отменить эффект известного ввода; (2) если состояние всего пула утекло, злоумышленник может установить все биты в пуле в ноль. Его новый дизайн, который быстрее и безопаснее, использует хэш-функцию blake2s для смешивания 256-битного пула. [19]
Операционная система FreeBSD предоставляет ссылку /dev/urandom на /dev/random . Оба блокируются только до тех пор, пока не будут правильно засеяны. PRNG FreeBSD ( Fortuna ) регулярно засеивает и не пытается оценить энтропию. В системе с небольшим объемом сетевой и дисковой активности засеивание выполняется за доли секунды. [20]
DragonFly BSD унаследовал файлы случайных устройств FreeBSD, когда был разветвлен. [21] [ необходим неосновной источник ] [22]
Начиная с OpenBSD 5.1 (1 мая 2012 г.) /dev/random и /dev/arandom используют arc4random , функцию CSPRNG на основе RC4 . Функция была изменена для использования более сильного ChaCha20 с OpenBSD 5.5 (1 мая 2014 г.). Система автоматически использует аппаратные генераторы случайных чисел (например, те, которые предоставляются на некоторых концентраторах Intel PCI), если они доступны, через OpenBSD Cryptographic Framework . [23] [24] /dev/arandom был удален в OpenBSD 6.3 (15 апреля 2018 г.). [25]
Реализация устаревшего API NetBSDarc4random() также была переключена на ChaCha20. [26]
Все операционные системы Apple перешли на Fortuna как минимум с декабря 2019 года, возможно, и раньше. [27] Он основан на SHA-256 . Используются несколько источников энтропии, таких как безопасный анклавный RNG, джиттер синхронизации фазы загрузки, аппаратное прерывание (предполагаемое время). RDSEED/RDRAND используется на компьютерах Mac на базе Intel, которые его поддерживают. Данные начального значения (энтропии) также сохраняются для последующих перезагрузок.
До этого изменения macOS и iOS использовали 160-битный Yarrow на основе SHA-1 . [28]
Нет никакой разницы между /dev/random и /dev/urandom ; оба ведут себя одинаково. [29] [30]
/dev/random и /dev/urandom также доступны в Solaris, [31] NetBSD, [32] Tru64 UNIX 5.1B, [33] AIX 5.2 [34] и HP-UX 11i v2. [35] Как и в FreeBSD, AIX реализует собственную конструкцию на основе Yarrow, однако AIX использует значительно меньше источников энтропии, чем стандартная реализация /dev/random , и прекращает пополнение пула, когда считает, что он содержит достаточно энтропии. [36]
В Windows NT подобная функциональность предоставляется ksecdd.sys , но чтение специального файла \Device\KsecDD не работает как в UNIX. Документированными методами генерации криптографически случайных байтов являются CryptGenRandom и RtlGenRandom . Windows PowerShell предоставляет доступ к криптографически безопасному генератору псевдослучайных чисел через командлет Get-SecureRandom . [37]
Cygwin на Windows предоставляет реализации как /dev/random, так и /dev/urandom , которые можно использовать в скриптах и программах. [38]
Есть ли какой-либо серьезный аргумент в пользу того, что постоянное добавление новой энтропии — это хорошо? На странице руководства Linux /dev/urandom утверждается, что без новой энтропии пользователь "теоретически уязвим для криптографической атаки", но (как я уже упоминал в разных местах) это смехотворный аргумент
Генератор случайных чисел на основе ChaCha для OpenBSD.
/dev/arandom удален из OpenBSD.
Устаревший arc4random(3) API из OpenBSD, переработанный с использованием ChaCha20 PRF, с состоянием для каждого потока.
