Недавно директор ФБР Джеймс Коми выступил с докладом, на котором выразил неудовольствие массовым внедрением шифрования в смартфоны и прочие средства коммуникаций, выразив надежду на принятие законов, требующих предоставлять ФБР ключи шифрования. Так, Коми выразил недовольство тем, что все постоянно подключаются к разным точкам Wi-Fi, а все больше сервисов и программ использует шифрование на стороне клиента. Это в свою очередь вызвало бурную ответную реакцию в среде специалистов по безопасности. Наиболее интересным можно посчитать выступление известного специалиста по безопасности и шифрованию Дэниеля Бернштейна (Daniel J. Bernstein).

В своём выступлении Бернштейн рассматривает типовые практики спецслужб, нацеленные на борьбу с криптографией. Можно отметить, что спецслужбами практикуются как минимум следующие моменты:

Долговременные стратегии по взаимодействию с коммерческими структурами:

  • Внедрение уязвимостей в коммерческие средства шифрования, компьютерные системы и устройства, используемые потенциальными мишенями.
  • Сбор данных и метаданных о цели за счет задействования дружественных провайдеров и усиление контроля над магистральными (core) частями сети.
  • Усиление использования коммерческих методов доставки и получения информации, касающейся мишени.
  • Изучение возможностей взлома и эксплуатации иностранных вариантов технологий, наподобие trusted computing.
  • Оказание влияния на стандарты, политики и спецификации для коммерческих технологий на основе криптографии по открытым ключам.
  • Агрессивное инвестирование в изучение способов взлома беспроводных сетей нового поколения.

Прочие стратегии:

  • Манипулирование экосистемой программного обеспечения, для того чтобы программное обеспечение оставалось небезопасным.
  • Взлом компьютеров для получения доступа к миллионам жестких дисков, содержимому экрана, камерам, микрофонам и т.п..
  • Внедрение черных ходов в оборудование.

Далее Бернштейн проводит мысленный эксперимент: как может выглядеть влияние на экосистему программного обеспечения для насаждения небезопасных алгоритмов в программном обеспечении в данный момент времени?

Атаки, основанные на изучении времени выполнения алгоритмов.

  • Например, AES в большинстве реализаций используется доступ к таблице (lookup table). Доступ к элементам таблицы зависит от используемого ключа. Это вызывает изменение состояния кэша процессора. Все это может позволить восстановить ключ, проделав всего лишь серию измерений времен, нацеленных на изучение использования кэша процессора. Исследователи Osvik, Shamir и Tromer показали еще в 2005 году, как за 65 миллисекунд можно получить ключ шифрования AES из ядра Linux. Все, что для этого требуется - возможность запуска процесса без каких либо специальных привилегий на том же процессорном ядре.
  • В 2011 году Brumley и Tuveri смогли восстановить приватный ключ ECDSA в случае OpenSSL за считанные минуты, используя тот факт, что условные переходы зависят от секретного ключа.
  • Существует множество иных подвидов этой атаки. Например, в случае IPSec при проверке целостности сообщения (MAC) - как правило используется функция memcmp, завершающаяся за различное время для различных случаев. А в 2014 году исследователи van de Pol, Smart и Yarom смогли восстановить приватный ключ, используемый в кошельке Bitcoin за всего 25 подписей, сформированных этим ключом.

В этом направлении Бернштейн выделяет явно неверный отчет от NIST 2001 года. В нем правильно констатируется, что криптографические операции шифрования и расшифровки должны завершаться за постоянное время, независимо от ключа и входных данных, однако этот же отчет почему-то утверждает, что доступ к значениям таблиц является операцией занимающей постоянное время, что не соответствует действительности. Или например RFC 5246 утверждает, что утечки информации о времени операций - "незначительные", что похоже на попытку принизить значимость этого фактора. А в 2013 году исследователи AlFardan и Paterson смогли в результате взломать TLS 1.2 и DTLS и получить нешифрованный вариант текста.

Ряд операций процессора не требует операций с памятью и поэтому, как правило, имеют постоянное время выполнения. В частности, обычно это команды логических операций, сдвиг на постоянное количество битов, умножение (на большинстве процессоров), сложение и вычитание. Тем не менее, вполне возможно, что может проводиться работа по финансированию "ненадежных" программ и показательное преуменьшение и маскировка проблемы, а также распространение скептических мнений наподобие "такие реализации алгоритмов будут слишком медленными и их очень сложно написать".

Бернштейн иронизирует: "а что если кто-то сделает простой и быстрый алгоритм, отрабатывающий за постоянное время?! В этом случае - ни в коем разе не дайте его принять как стандарт! Протолкайте лучше AES, с его проблемами с разным временем доступа, ни в коем случае не принимайте как стандарт более безопасный Serpent, где таких проблем нет. Всячески пытайтесь показать, что именно стандартизация - ключ к надежности, а нестандартные алгоритмы, дескать, могут иметь неизвестные уязвимости".

Атаки на добавочное заполнение (padding oracle)

Вредный совет от Бернштейна, который понравится ФБР: прогоняйте поддельные сообщения от атакующего через максимально возможное количество стадий обработки до того, как принять решение о некорректности этого сообщения. Например, расшифруйте сообщение и проверьте добавочное заполнение (padding) ДО того как проверять целостность (MAC) сообщения по серьезной криптографической функции. Это позволит утечь достаточному объему информации о корректности "добавки" сообщения и в конечном итоге атакующий сможет успешно угадать зашифрованный текст сделав несколько запросов к "оракулу", которым как правило выступает сервер (актуально в основном для блочных шифров шифров в режиме CBC). Результат? Атаки BEAST и PUDDLE на SSL. Аналогичные по смыслам атаки с задействованием "encrypt-only" опций IPSec. И "неожиданная" публикация атак на реализацию IPSec в Linux в 2006 году и на реализацию IPSec из RFC в 2007.

Неслучайная случайность.

  • В 1995 году как-то совершенно случайно оказалось, что приватные ключи, сгенерированные Netscape, содержат всего 50 битов энтропии и, соответственно, любой ключ можно угадать за обозримое время.
  • А в 2008 году оказалось, что секретные ключи в Debian/Ubuntu содержат лишь 20 битов энтропии и составить исчерпывающий список всех возможных ключей - легко реализуемая с практической точки зрения задача.
  • В 2012 году ряд исследователей смогли получить секретные ключи для 0.5% всех SSL-серверов. Простые числа были настолько неслучайными, что в 0.5% случаев просто произошли коллизии и у исследователей оказались приватные ключи парные к публичным ключам этих серверов.

Вредные советы? Сделайте код генерации случайных чисел максимально сложным, чтобы в нем никто никогда не разобрался. Пусть каждое приложение таскает свою реализацию генератора случайных чисел, "для скорости". А для упрощения жизни программиста неплохо бы схалтурить в реализации генератора случайных чисел, чего-нибудь необдуманно упростив. Доплачивайте тем, кто использует пробэкдоренные RNG, например как Dual EC (реализация PRNG от NIST в которой недавно был обнаружен бэкдор) и козыряйте "проверенной" безопасностью "стандартных" решений. Не в коем случае не вздумайте смешивать источники энтропии в большой пул. А то чего доброго у вас может получится проверяемый процесс смешивания и достаточно большой пул, переживающий множество генераций случайных чисел с сохранением достаточного качества энтропии.

Активно дискредитируйте идею центральных пулов энтропии. Утверждайте, что это "тормозит". Сделайте пул непригодным к использованию (random) или отпугивающим программиста своим видом (urandom). А что если эти негодяи осознают что скорость получения энтропии - не такая уж и проблема? Сделайте это проблемой! Сделайте так чтобы ваша криптография как можно чаще и больше хотела случайные числа. К тому же это усложняет тестирование и помогает удачно сделать несколько лишних ошибок. Таковы например DSA и ECDSA. Хотя наиболее эпичным провалом можно признать ошибку фирмы Sony, использовавшей одно и то же случайное число для своей реализации криптографии на эллиптических кривых, что позволило исследователям восстановить секретный ключ.

Злостные ошибки в применении криптографии.

  • Использование MD5. Кроме всего прочего, благодаря коллизиям исследователи смогли создать поддельные CA для протокола TLS и в целом MD5 стал достаточно большой проблемой. Однако намного менее известен тот факт, что в 1996 году, всего несколько лет после выхода алгоритма MD5, несколько исследователей призвали отправить этот алгоритм в утиль. Почему так? Спасибо агрессивному муссированию тематики стандартов, скорости работы и совместимости.
  • В 2014 году стандарт DNSSEC всерьез предлагает использовать ключи RSA размером всего 1024 бита. Хотя еще в 2003 году исследователи оценили сложность вскрытия RSA-1024 в примерно год при бюджете 10 миллионов долларов. Бернштейн иронизирует, что IP-адрес внедренцев dnssec-deployment.org показательно подписан "очень надежным" 1024-битным ключом RSA. Аргументы за такое решение? "Компромисс между скоростью и сложностью взлома".

    Как убедить "потенциальных террористов" что надежная криптография слишком медленная? Множество методов: подсовывать устаревшие данные, некомпетентно выполненные тесты, откровенно жульничать в результатах. Например, в PRESERVE (набор стандартов для коммуникаций автомобиль-автомобиль и автомобиль-дорожная инфраструктура) утверждается, что современные процессоры, даже мощные, наподобие Pentium-D 3.4GHz, не справятся с шифрованием пакетов и якобы потребуется отдельный криптопроцессор. С другой стороны Бернштейн приводит выкладки, показывающие что при использовании алгоритмов Salsa20, poly1305 и curve 25519 в оптимизированном варианте для Cortex A8 с использованием команд NEON - с задачей шифрования и верификации пакетов справится даже Cortex A8 на 1ГГц, не являющийся чем-то сверхъестественным. Ну разумеется, новый стандартный протокол ни в коем разе нельзя делать с использованием быстрых и безопасных алгоритмов. А то вдруг еще получится невскрываемым?!

  • Разумеется, при желании сделать криптографию ненадежной - следует максимально усложнить протокол и назвать это "гибкостью". Хотя правильнее было бы назвать это "хрупкостью". SSL и TLS служат отличным примером.
  • Бывают и совсем странные случаи. Например, нужда в шифровании SNI отвергается под предлогом отсутствия шифрования DNS-запросов, а аргументы за шифрование DNS-запросов отвергаются под предлогом того что SNI все-равно не шифрованный.
  • Настаивайте на предварительных вычислениях. Например, DNSSEC "для скорости" позволяет посчитать подпись заранее.

Откровенные аферы:

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


Источник: http://www.opennet.ru/opennews/art.shtml?num=40877