Разработчики FreeBSD нашли в процессорах Intel преднамеренно ослабленную криптографию
Разработчики операционной системы FreeBSD больше не позволят пользователям выбирать процессоры производства Intel и Via Technologies как единственный источник случайных чисел при генерации криптографических ключей. Есть вероятность, что эти чипы содержат умышленно ослабленный криптографический модуль, чтобы предоставить доступ к криптографическим ключам для правительственных агентств.
Изменения вступили в силу с версии FreeBSD 10.0, которая вышла спустя три месяца после публикации документов Сноудена, свидетельствующих о массовой слежке АНБ с перехватом и расшифровкой интернет-трафика.
Речь идет об аппаратных ГСЧ от Intel и Via Technologies: функции RDRAND и Padlock, соответственно. Отныне операционная система перестанет напрямую брать поток случайных чисел от этих ГСЧ для /dev/random, а будет пропускать его через алгоритм дополнительной рандомизации под названием Yarrow. Он добавит необходимый уровень энтропии, чтобы гарантировать неработоспособность потенциальных бэкдоров или уязвимостей.
«Возможность прямого доступа к аппаратным генераторам RDRAND, Padlock и проч. остается через встроенный ассемблер или из запущенной пользователем программы OpenSSL, если это кому-то нужно, но мы больше не можем доверять им», — говорят разработчики FreeBSD.
Комментарии
MrBison
15 декабря, 2013 - 19:55
Опять скандальный заголовок.
Правильнее будет:
"Разработчики FreeBSD
нашлиподозревают, что в процессорах Intel преднамеренноослабленную криптографиюослаблены генераторы случайных чисел"Если серьёзно же, то даже если в процессорах Intel и Via действительно ослаблены, с целью занижения энтропии, ГСЧ, то эффективность бэкдора будет зависеть от множества переменных:
1. ОС, используемой пользователем. Windows, Linux и FreeBSD теперь все берут свои случайные числа по-разному.
2. ПО, которое использует юзер. Некоторый софт вообще не использует системный ГСЧ, а взамен берёт энтропию из нажатых клавиш или движений мыши (например, генератор ключей OpenSSL или TrueCrype).
3. Параллельно запущенное ПО, которое также может использовать (читать или писать в) ГСЧ. В линуксе, например, тот же /dev/random доступен для записи всем пользователям. Если написать программу, которая будет брать случайные числа из постороннего источника и писать их в /dev/random, то можно подпортить потенциальным правительственным подслушивателям их попытки помешать пользователю (чё-то сплошные П получились). Это даже Теодор Тсо рекомендует:
pomodor
16 декабря, 2013 - 14:54
Гражданин Бизон, если бы Вы хоть немного разбирались в новостной журналистике, то знали бы, что слово «подозревают» не только в 10 раз скучнее слова «нашли», но и сам факт подозрений никому не интересен. Более того, он указывает на отсутствие новостного повода как такового.
Пример:
«ФАС в Коми подозревает оптовиков в завышении цен на яйца»
Цены — это конкретные цифры. Пришел в магаз и посмотрел: либо завышают, либо нет. А когда ФАС «подозревает», то новость следует читать так «ФАС до лампочки цены на яйца» или даже «ФАС бездействует». Поскольку бездействие является обычным состоянием ФАС, то новость отсутствует. Это как писать «новости» о том, что елка зеленая, а небо голубое.
Поэтому новость с заголовком о подозрениях не имеет право на существование.
Ну и в качестве домашнего задания подумайте над следующим заголовком:
«Spiegel: Советские ученые нашли дорогу в ад». Почему именно такой заголовок? Ведь если бы в Шпигеле, не дай бог, работал бы Мистер Бизон, то заголовок получился бы таким: «Spiegel: Советские ученые
нашлипредположили, что нашли дорогу вадместо религиозного назначения». ;) Ведь как можно найти то, доказательства существования чего до сих пор не предоставлены? И тем не менее, журналист использовал именно слово «нашли». Как Вы думаете, уважаемый специалист по правильным заголовкам, почему? ;)pomodor
16 декабря, 2013 - 15:40
А насчет /dev/random не знал. Точнее, даже предположить не мог, что такая глупость может существовать. Действительно, файл открыт для записи всем желающим. Будет интересно провести эксперимент: запихивать туда данные с низкой энтропией и посмотреть как это отразится на качестве получаемых псевдослучайных чисел.
MrBison
21 декабря, 2013 - 19:32
Как бы это не «глупость», а фича, предназначенная для того, чтобы можно было при необходимости писать в ГСЧ свои случайные данные.
Из предложений интернета: захэшированные данные с веб-камеры, белый шум динамиков, те же нажатия клавиш клавиатуры или мыши...
Данные при этом смешиваются таким образом, что невозможно посредством подачи каких-либо данных _навредить_ генерации СЧ.
http://lkml.indiana.edu/hypermail/linux/kernel/0012.2/0502.html
Кстати, если вы действительно верите, что RdRand опасен для вашей криптографии, то просто отредактируйте ваш GRUBовский конфиг и добавьте параметр nordrand ;)
http://linux.slashdot.org/comments.pl?sid=4191765&cid=44807433
pomodor
23 декабря, 2013 - 14:46
Пройдя по Вашей ссылке можно узнать, что в SuSE Linux на /dev/random стоят права 644. Хотите сказать, что один из успешных коммерческих дистрибутивов разрабатывают идиоты? ;)
MrBison
24 декабря, 2013 - 08:32
Ну, пройдя по моей же ссылке можно прочитать ответ:
pomodor
24 декабря, 2013 - 17:17
Я же написал, что по ссылке переходил. Или Вы демонстрируете умение пользоваться тэгом blockquote?
Вопрос не в том, что считает Тсо. Вопрос в том, почему другие солидные люди целенаправленно изменили права доступа к /dev/random и какими соображениями при этом руководствовались.
Концептуально разработчики openSUSE правы. В качестве генерации ПСЦ заинтересован админ, поэтому только root и должен влиять на /dev/random, а остальные только читать. В крайнем случае, можно дать доступ еще и группе. Но зачем, например, давать права записи в /dev/random web-серверу или FTP-юзеру? Одно из фундаментальных правил при построении политики безопасности — давать минимально необходимый уровень полномочий.
pomodor
16 декабря, 2013 - 16:55
Результаты эксперимента с записью в /dev/urandom.
Написал программку, которая n раз считывает символ из /dev/urandom и строит таблицу частотности для всех символов от 0 до 255. Понятно, что чем большее количество итераций n, тем ближе частотность каждого символа приближается к общему значению. Выбираем n = 100 000 000 и запускаем. Результат сохраняем.
Теперь в фоне запустим скрипт:
while true ; do echo «Жопа» > /dev/random ; done
И повторяем операцию, описанную выше. Затем сравниваем частотности до и после вмешательства.
Результаты проверки показали, что засирание /dev/random не сказывается на частотных характеристиках получаемых псевдослучайных чисел.
Комментировать