По-видимому, / dev / random основан на аппаратных прерываниях или подобных непредсказуемых аспектах физического оборудования. Поскольку виртуальные машины не имеют физического оборудования, cat /dev/random внутри виртуальной машины ничего не производит. Я использую Ubuntu Server 11.04 в качестве хоста и гостя с libvirt / KVM.
Мне нужно настроить Kerberos внутри виртуальной машины, но krb5_newrealm просто навсегда зависает «Загрузка случайных данных», так как система их не производит.
Кто-нибудь знает, как это обойти? Можно ли передать хост / dev / random (который очень болтлив) в виртуальную машину, чтобы виртуальная машина могла использовать его случайные данные?
Я читал, что есть некоторые программные альтернативы, но они не подходят для криптологии, поскольку не достаточно случайны.
РЕДАКТИРОВАТЬ: Похоже, что cat / dev / random на vm действительно производит вывод, очень, очень медленно. Я настроил свою область, подождав около двух часов, пока идет «Загрузка случайных данных». В конце концов этого хватило, чтобы продолжить. Тем не менее, меня все еще интересует способ ускорить это.
Я использую hasged на всех моих безголовых серверах, которые выполняют криптографические операции (например, рукопожатия TLS, Kerberos и т. Д.). Он должен быть в репозитории пакетов большинства версий Ubuntu: http://packages.ubuntu.com/search?keywords=haveged&searchon=names&suite=all§ion=all
hasged использует алгоритм HAVAGE для извлечения энтропии из внутреннего состояния современных процессоров. Вот подробное объяснение: http://www.irisa.fr/caps/projects/hipsor/
Вы можете проверить случайность генерируемой энтропии с помощью пакета ent. В моих системах сгенерированная энтропия из hasged прошла все тесты на случайность по ent
Он должен «просто работать». Несмотря на то, что виртуальная машина не имеет специального физического оборудования, она все еще имеет доступ к нескольким очень хорошим источникам случайности. Например, он может использовать TSC ЦП для измерения времени чтения с виртуальных дисков, что в конечном итоге приведет к сокращению времени физических дисков до миллиардной доли секунды. Эти тайминги зависят от турбулентного сдвига воздушного потока на жестком диске, что непредсказуемо.
Аналогичная логика применима к сетевому трафику. Несмотря на то, что интерфейс виртуализирован, до тех пор, пока пакет исходит из физической сети (и не является локальным для бокса, скажем, исходящим из другой виртуальной машины), синхронизация пакета зависит от фазового сдвига между кварцевым генератором на сетевой карте. и кварцевый генератор, который управляет TSC. Это зависит от изменений температуры микроскопических зон в двух кристаллах кварца. Это тоже непредсказуемо.
Если по какой-то причине он не работает, самое простое решение - написать программу для добычи энтропии и добавить ее в системный пул. Сетевой интерфейс - ваш самый надежный источник. Например, вы можете написать код для:
1) Запросите TSC.
2) Отправьте DNS-запрос серверу, о котором известно, что он не находится на той же физической машине.
3) Запросите TSC, когда запрос завершится.
4) Повторите это несколько раз, суммируя все значения TSC.
5) Выполните безопасное хеширование для накопленных функций TSC.
6) Передайте вывод защищенной хеш-функции в пул энтропии системы.
7) Следите за уровнем энтропийного пула и ждите, пока он не опустится. Когда это произойдет, вернитесь к шагу 1.
В Linux есть простые вызовы IOCTL для добавления энтропии в пул, проверки уровня пула и т. Д. У тебя наверное есть rngd, который может брать энтропию из канала и передавать ее в системный пул. Вы можете заполнить канал из любого источника, который захотите, будь то запросы TSC или wget из вашего собственного источника энтропии.
Да, вы можете засеять это из:
http://manpages.ubuntu.com/manpages/jaunty/man4/random.4.html
Вы можете просто поместить это в / dev / urandom, и он должен заполнить пул энтропии. Я смог подтвердить это:
root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail
128
root@mx01-ewr:/proc/sys/kernel/random# cat /dev/xvda >/dev/urandom &
[1] 16187 # just using this as a source of data, you could do ssh hostIP 'cat /dev/random' >... etc
root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail
1221
root@mx01-ewr:/proc/sys/kernel/random# cat entropy_avail
1398
Бонус, если вы заставите команду ssh проходить через маршрутизатор, чтобы она генерировала энтропию * :)
Это сработало для меня
Выполнение krb5_newrealm внутри виртуальной машины может занять много времени (после отображения сообщения «Загрузка случайных данных»). Вы можете использовать следующий прием, чтобы немного ускорить процесс.
$ sudo aptitude install rng-tools -y
$ sudo rngd -r /dev/urandom -o /dev/random # don't do this in production!
размещено на http://fossies.org/linux/john/doc/Kerberos-Auditing-HOWTO.md
Ответ X86 - убедиться, что ваша виртуальная машина не перехватывает RdRand или RdSeed. Вы во многом доверяете своей виртуальной машине, и это одна из них.
Достаточно недавний RNGd на пост-процессоре Snady Bridge будет (или может быть сказано) использовать RdRand или RdSeed, а необработанный RdRand или RdSeed получает энтропию в виртуальную машину. Затем / dev / random работает с реальным (не виртуальным) источником энтропии.
Это не случайно. Это прямо в документации по архитектуре Intel.
Для источника аппаратной энтропии на основе устройства (например, использует драйвер ядра для совместного использования) вам нужна виртуальная машина для правильной виртуализации физического источника. Понятия не имею, делают ли они это, и если да, то для каких устройств.
Если у вашего RNGd нет опции drng ниже, обновите ее. Если на вашем оборудовании нет быстрого аппаратного ГСЧ, вы обречены, и вам следует подумать об использовании другого оборудования в целях безопасности.
# rngd --help
Usage: rngd [OPTION...]
Check and feed random data from hardware device to kernel entropy pool.
-b, --background Become a daemon (default)
**-d, --no-drng=1|0 Do not use drng as a source of random number input**
(default: 0)
-f, --foreground Do not fork and become a daemon
-n, --no-tpm=1|0 Do not use tpm as a source of random number input
(default: 0)
-o, --random-device=file Kernel device used for random number output
(default: /dev/random)
-p, --pid-file=file File used for recording daemon PID, and multiple
exclusion (default: /var/run/rngd.pid)
-q, --quiet Suppress error messages
-r, --rng-device=file Kernel device used for random number input
(default: /dev/hwrng)
-s, --random-step=nnn Number of bytes written to random-device at a time
(default: 64)
-v, --verbose Report available entropy sources
-W, --fill-watermark=n Do not stop feeding entropy to random-device until
at least n bits of entropy are available in the
pool (default: 2048), 0 <= n <= 4096
-?, --help Give this help list
--usage Give a short usage message
-V, --version Print program version
Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
Report bugs to Jeff Garzik <jgarzik@pobox.com>.
У меня тоже были проблемы с зависанием krb5_newrealm. Это сработало для меня, основываясь на приведенном выше ответе:
cat /dev/sda > /dev/urandom
Возможно, вы захотите убить его, когда закончите работу со случайными данными. / dev / sda, вероятно, содержит больше данных, чем вам нужно.
Примечание: я не уверен, насколько на самом деле случайные данные, сгенерированные таким образом, случайны.