Разработчики FreeBSD нашли в процессорах Intel преднамеренно ослабленную криптографию

Разработчики операционной системы FreeBSD больше не позволят пользователям выбирать процессоры производства Intel и Via Technologies как единственный источник случайных чисел при генерации криптографических ключей. Есть вероятность, что эти чипы содержат умышленно ослабленный криптографический модуль, чтобы предоставить доступ к криптографическим ключам для правительственных агентств.

Изменения вступили в силу с версии FreeBSD 10.0, которая вышла спустя три месяца после публикации документов Сноудена, свидетельствующих о массовой слежке АНБ с перехватом и расшифровкой интернет-трафика.

Речь идет об аппаратных ГСЧ от Intel и Via Technologies: функции RDRAND и Padlock, соответственно. Отныне операционная система перестанет напрямую брать поток случайных чисел от этих ГСЧ для /dev/random, а будет пропускать его через алгоритм дополнительной рандомизации под названием Yarrow. Он добавит необходимый уровень энтропии, чтобы гарантировать неработоспособность потенциальных бэкдоров или уязвимостей.

«Возможность прямого доступа к аппаратным генераторам RDRAND, Padlock и проч. остается через встроенный ассемблер или из запущенной пользователем программы OpenSSL, если это кому-то нужно, но мы больше не можем доверять им», — говорят разработчики FreeBSD.

Реакция Линуса Торвальдса на бэкдор в процессорах Intel

В сентябре 2013 года эту уязвимость обсуждали разработчики ядра Linux. Тогда Линус Торвальдс выступил в своей привычной манере а-ля «вы все дураки — один я эксперт». Опасаясь неадекватной эмоциональной реакции г-на Торвальдса, разработчики решили не учитывать возможное влияние бэкдора на работу генератора псевдослучайных чисел в ядре Linux.

Ваша оценка: Нет Средняя оценка: 5 (1 vote)
8

Опять скандальный заголовок.

Правильнее будет:
"Разработчики FreeBSD нашли подозревают, что в процессорах Intel преднамеренно ослабленную криптографию ослаблены генераторы случайных чисел"

Если серьёзно же, то даже если в процессорах Intel и Via действительно ослаблены, с целью занижения энтропии, ГСЧ, то эффективность бэкдора будет зависеть от множества переменных:

1. ОС, используемой пользователем. Windows, Linux и FreeBSD теперь все берут свои случайные числа по-разному.

2. ПО, которое использует юзер. Некоторый софт вообще не использует системный ГСЧ, а взамен берёт энтропию из нажатых клавиш или движений мыши (например, генератор ключей OpenSSL или TrueCrype).

3. Параллельно запущенное ПО, которое также может использовать (читать или писать в) ГСЧ. В линуксе, например, тот же /dev/random доступен для записи всем пользователям. Если написать программу, которая будет брать случайные числа из постороннего источника и писать их в /dev/random, то можно подпортить потенциальным правительственным подслушивателям их попытки помешать пользователю (чё-то сплошные П получились). Это даже Теодор Тсо рекомендует:

One of the things which I would strongly recommend to
security applications, such as those found in the OpenWRT Linux
distribution, is to calculate the cryptographic hash of data which is
to be sent out encrypted, and write that into /dev/random, thus mixing
that hash into the entropy pool. This will not provide any entropy
credits (since at least one entity would have knowledge of the value
of the hash). However, to attackers that do *not* have access to the
plaintext of the encrypted communications sent out by the application,
this unknown data will significantly complicate the life of attackers
attempting to analyze the state of the random number generator. In
the absence of hard drive-generated entropy or human-generated timing
data from a keyboard or pointing device, it's certainly better than
nothing, and in practice is quite effective.

Ваша оценка: Нет
11
pomodor

Гражданин Бизон, если бы Вы хоть немного разбирались в новостной журналистике, то знали бы, что слово «подозревают» не только в 10 раз скучнее слова «нашли», но и сам факт подозрений никому не интересен. Более того, он указывает на отсутствие новостного повода как такового.

Пример:
«ФАС в Коми подозревает оптовиков в завышении цен на яйца»
Цены — это конкретные цифры. Пришел в магаз и посмотрел: либо завышают, либо нет. А когда ФАС «подозревает», то новость следует читать так «ФАС до лампочки цены на яйца» или даже «ФАС бездействует». Поскольку бездействие является обычным состоянием ФАС, то новость отсутствует. Это как писать «новости» о том, что елка зеленая, а небо голубое.

Поэтому новость с заголовком о подозрениях не имеет право на существование.

Ну и в качестве домашнего задания подумайте над следующим заголовком:
«Spiegel: Советские ученые нашли дорогу в ад». Почему именно такой заголовок? Ведь если бы в Шпигеле, не дай бог, работал бы Мистер Бизон, то заголовок получился бы таким: «Spiegel: Советские ученые нашли предположили, что нашли дорогу в ад место религиозного назначения». ;) Ведь как можно найти то, доказательства существования чего до сих пор не предоставлены? И тем не менее, журналист использовал именно слово «нашли». Как Вы думаете, уважаемый специалист по правильным заголовкам, почему? ;)

Ваша оценка: Нет Средняя оценка: 5 (1 vote)
11
pomodor

А насчет /dev/random не знал. Точнее, даже предположить не мог, что такая глупость может существовать. Действительно, файл открыт для записи всем желающим. Будет интересно провести эксперимент: запихивать туда данные с низкой энтропией и посмотреть как это отразится на качестве получаемых псевдослучайных чисел.

Ваша оценка: Нет Средняя оценка: 3 (1 vote)
8

Как бы это не «глупость», а фича, предназначенная для того, чтобы можно было при необходимости писать в ГСЧ свои случайные данные.

Из предложений интернета: захэшированные данные с веб-камеры, белый шум динамиков, те же нажатия клавиш клавиатуры или мыши...

Данные при этом смешиваются таким образом, что невозможно посредством подачи каких-либо данных _навредить_ генерации СЧ.

http://lkml.indiana.edu/hypermail/linux/kernel/0012.2/0502.html

Кстати, если вы действительно верите, что RdRand опасен для вашей криптографии, то просто отредактируйте ваш GRUBовский конфиг и добавьте параметр nordrand ;)

http://linux.slashdot.org/comments.pl?sid=4191765&cid=44807433

Ваша оценка: Нет
11
pomodor

Пройдя по Вашей ссылке можно узнать, что в SuSE Linux на /dev/random стоят права 644. Хотите сказать, что один из успешных коммерческих дистрибутивов разрабатывают идиоты? ;)

Ваша оценка: Нет
8

Ну, пройдя по моей же ссылке можно прочитать ответ:

It does mix data into the pool, but the mixing algorithm is designed so that you can do no harm by mixing any data into the pool — even nasty data chosen by an attacker. Hence, allowing someone to write into /dev/random is perfectly safe; it can cause no damage, and might improve things. That's why /dev/random should be world-writeable.

Ваша оценка: Нет
11
pomodor

Я же написал, что по ссылке переходил. Или Вы демонстрируете умение пользоваться тэгом blockquote?

Вопрос не в том, что считает Тсо. Вопрос в том, почему другие солидные люди целенаправленно изменили права доступа к /dev/random и какими соображениями при этом руководствовались.

Концептуально разработчики openSUSE правы. В качестве генерации ПСЦ заинтересован админ, поэтому только root и должен влиять на /dev/random, а остальные только читать. В крайнем случае, можно дать доступ еще и группе. Но зачем, например, давать права записи в /dev/random web-серверу или FTP-юзеру? Одно из фундаментальных правил при построении политики безопасности — давать минимально необходимый уровень полномочий.

Ваша оценка: Нет Средняя оценка: 5 (3 votes)
11
pomodor

Результаты эксперимента с записью в /dev/urandom.

Написал программку, которая n раз считывает символ из /dev/urandom и строит таблицу частотности для всех символов от 0 до 255. Понятно, что чем большее количество итераций n, тем ближе частотность каждого символа приближается к общему значению. Выбираем n = 100 000 000 и запускаем. Результат сохраняем.

Теперь в фоне запустим скрипт:

while true ; do echo «Жопа» > /dev/random ; done

И повторяем операцию, описанную выше. Затем сравниваем частотности до и после вмешательства.

Результаты проверки показали, что засирание /dev/random не сказывается на частотных характеристиках получаемых псевдослучайных чисел.

Ваша оценка: Нет Средняя оценка: 5 (2 votes)
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.
Linux I класса
Linux II класса
Linux III класса
Счетчики
  • Самый популярный сайт о Linux и Windows 10
О Либератуме

Liberatum — это новости мира дистрибутивов Linux, обзоры, сборки, блоги, а также лучший сайт об Ubuntu*.