Новая атака на схему симметричного шифрования в OpenPGP
Эта новость поступила только около часа назад, и я успел ознакомиться с деталями лишь поверхностно. Однако, и хочу это сразу подчекнуть, атака носит ограниченно-прикладной характер, и неприменима ни к одной существующей реализации стандарта OpenPGP!
Мистер и Цуккерато, как Шнайер, Джеллад и Катц, использовали методы адаптивно подобранного шифртекста и дешифрующего оракула. В случае успеха оппонент сможет восстанавливать первые два байта из любого блока шифртекста при 2^15 (в среднем) запросов к оракулу на каждый (два часа в лабораторных условиях на стандартном Pentium M 1.8 ГГц). Это несравнимо меньше, чем при успешной атаке Шнайера-Джеллада-Катца, где одного подобранного шифртекста, переданного оракулу, достаточно (при определённых условиях), чтобы дешифровать весь открытый текст единичного сообщения.
Итак, суть в следующем. Каждый симметрично зашифрованный пакет данных предваряется 64- или 128-битовым вектором инициализации. Когда открытый текст шифруется, в самом начале пакета непосредственно перед "полезной нагрузкой" вставляется так называемый QC-тэг (quick check, быстрая проверка), состоящий из двух последних байт ВИ. Он служит тому, чтобы при расшифровании можно было сразу узнать, используется ли правильный симметричный ключ или неверный и, в случае чего, не прогонять расшифрование по всему сообщению: если расшифрованный QC-тэг совпадает с последними байтами ВИ, программа продолжает расшифрование всего сообщения, иначе выдаёт ошибку. Это особенно полезно, если зашифрованные данные составляют несколько мегабайт или гигабайт — программе не нужно расшифровывать пакет целиком, чтобы в итоге определить, что операция проводится не тем ключом, и сообщить об этом пользователю. Вот за эту-то функцию и зацепились криптологи.
В предложенной ими схеме взломщику содействует дешифрующий оракул — лицо или программа, обладающая верным ключом расшифрования и которая может сообщить взломщику, прошло ли расшифрование нормально или с ошибкой.
Взломщик имеет в своём распоряжении сообщение, симметрично зашифрованное парольной фразой (это важно: сообщение, зашифрованное открытым ключом, не поддаётся такой атаке). Он вносит определённые изменения в пакет шифртекста и отправляет модифицированное сообщение оракулу, чтобы узнать, прошла ли "быстрая проверка". Если оракул возращает взломщику "Ошибка", взломщик снова вносит корректировку и повторяет процесс, пока, наконец, оракул не сообщит, что сообщение расшифровано, т.е., технически, подогнанные взломщиком байты QC-тэга совпали с последними байтами ВИ (оракул в результате расшифрования получит мусор, но это не важно). Теперь взломщик знает последние два байта ВИ. Он "сдвигает" ВИ на эти два байта и повторяет весь процесс, пока не получит полный вектор инициализации.
(В действительности, оракулу не обязательно возвращать "Правильно" или "Ошибка". Даже если при расшифровании мусора он всё равно сообщит взломщику "Ошибка", последний сможет провести тайминг-атаку, замерив время, затраченное на обработку сообщения.)
Это подготовительный этап, на который у исследователей уходило, в среднем, 4 часа. Исходя из полученных данных и при помощи специальных вычислений и дополнительных запросов к оракулу, можно за каждые 2 часа (в среднем) дешифровать по два первых байта из каждого блока шифртекста.
Как можно видеть, такая атака применима только против автоматизированных систем, выдающих избыточную информацию при взаимодействии с пользователем. Живой человек не станет отвечать "Правильно" или "Ошибка" и пытаться расшифровать около 30 тысяч присланных сообщений. Более того, на сегодня нет ни одной реализации OpenPGP, подходящей под необходимые допущения.
В то же время, в стандарт OpenPGP и в крупнейшие реализации — PGP и GnuPG — будут внесены соответствующие корректировки, запрещающие обработку QC-тэга в симметрично зашифрованных сообщениях.
комментариев: 9796 документов: 488 редакций: 5664
Ведь замедляют же специально вычисление ключа из пароля, а здесь ускоряют проверку!
Для коротких сообщений (а их может быть >95% случаев ) можно было бы сделать и медленную, зато более безопасную проверку (например от хэш-функции всего сообщения да еще с отдельным проверочным ВИ – IV-salt).
Для длинных – проверять хэши от первых нескольких блоков и т.д.
Обидно, что уязвимость возникает из-за несложной в устранении проблемы, такую проверку легко можно реализовать и более безопасных (пусть и немного медленных способов) – масса.
комментариев: 11558 документов: 1036 редакций: 4118
Предложения по исправлению данной ошибки уже есть. Судя по всему это будет хэш сеансового ключа, помещённый внутрь блока шифртекста вместа тэга quick check.
Думаю, что это достаточно хорошо описывает опасность связанную с quick-check, от которого я не хочу отказываться в данной реализации. Я уже спросил мнение одного из авторов статьи (S. Mister — я аспирант на той же кафедре, где он получил PhD в свое время), но пока нет ответа. Если будет, с удовольствием поделюсь.
комментариев: 11558 документов: 1036 редакций: 4118
Иначе говоря, если ключ неверен, приложение просто сохраняет молчание. Ответ и результат расшифрования выводятся только в случае успеха.
Либо ошибка выводится, но с задержкой в несколько секунд. Теоретически, от тайминг-атаки это не спасёт, но сделает её совершенно нереальной: оппоненту придётся всякий раз ждать означенное время, и проведение 30 тысяч тестов выйдет за пределы практической применимости. (Понятно, что и вывод результата успешного расшифрования должен производиться не ранее, чем через аналогичный срок, иначе, если производится дешифрование небольшого сообщения, оппонент не станет выжидать весь период задержки, а только время, максимально необходимое на легитимное расшифрование. По истечении этого времени он может повторять запрос, не дожидаясь предыдущего ответа.)
Решение проблемы может принести только новый вид пакета. Так же, как вместо No9 был придуман No18, нам нужен новый вид пакета который проверяет ключ в самом начале, скажем при помощи его хеширования в начале зашифрованного файла (хеш уже зашифрован).
Кстати, Sarge Mister мне ответил, и он с моими комментариями согласен.
комментариев: 11558 документов: 1036 редакций: 4118
Рандомизированная задержка еще лучше.
Но на самом деле, в большинстве случаев достаточна компрессия перед шифрованием. В этом случае четверть расшифрованного сообщения, которую с трудом может добыть противник ничего полезного для него не содержит. Так как стандарт OpenPGP поддерживает компрессию перед шифровкой, ее просто надо использовать не добавляя ничего в приложение.
Какие еще существуют реализации OpenPGP? Будут ли уже в следующей версии (например 9,1) внесены указанные изменения?
комментариев: 11558 документов: 1036 редакций: 4118