Заполнение атаки оракула

Криптографическая атака

В криптографии атака оракула заполнения — это атака, которая использует проверку заполнения криптографического сообщения для расшифровки зашифрованного текста. В криптографии сообщения открытого текста переменной длины часто приходится дополнять (расширять), чтобы они были совместимы с базовым криптографическим примитивом . Атака основана на наличии « оракула заполнения », который свободно отвечает на запросы о том, правильно ли заполнено сообщение или нет. Информация могла передаваться напрямую или просачиваться по побочным каналам .

Самая ранняя известная атака, в которой используется оракул заполнения, - это атака Блейхенбахера 1998 года, которая атакует RSA с заполнением PKCS # 1 v1.5 . ^[1] Термин «заполняющий оракул» появился в литературе в 2002 году, ^[2] после атаки Сержа Водене на дешифрование в режиме CBC , используемое в симметричных блочных шифрах . ^[3] Варианты обеих атак продолжают пользоваться успехом спустя более десяти лет после их первоначальной публикации. ^{[1] [4] [5]}

Асимметричная криптография

В 1998 году Дэниел Бляйхенбахер опубликовал основополагающую статью о так называемой атаке Блейхенбахера (также известной как «атака миллиона сообщений»). В атаке используется оракул заполнения против RSA с заполнением PKCS #1 v1.5 , но он не включает этот термин. Более поздние авторы классифицировали его атаку как атаку оракула. ^[1]

Мангер (2001) сообщает об атаке на замену заполнения PKCS #1 v1.5 на PKCS #1 v2.0 «OAEP». ^[6]

Симметричная криптография

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

По сравнению с атакой Блейхенбахера на RSA с помощью PKCS #1 v1.5, атака Водене на CBC гораздо более эффективна. ^[1] Обе атаки нацелены на широко используемые в то время криптосистемы: CBC — это исходный режим, используемый в Secure Sockets Layer (SSL) и продолжающий поддерживаться в TLS. ^[4]

Был предпринят ряд мер по смягчению последствий, чтобы предотвратить работу программного обеспечения для дешифрования в качестве оракула, но новые атаки, основанные на времени, неоднократно восстанавливали этот оракул. TLS 1.2 представляет ряд методов шифрования с аутентификацией и дополнительными режимами данных, которые не полагаются на CBC. ^[4]

Заполнение атаки оракула на шифрование CBC

Стандартная реализация дешифрования CBC в блочных шифрах заключается в расшифровке всех блоков зашифрованного текста, проверке заполнения, удалении заполнения PKCS7 и возврате открытого текста сообщения. Если сервер возвращает ошибку «недопустимое заполнение» вместо общей ошибки «не удалось расшифровать», злоумышленник может использовать сервер в качестве оракула заполнения для расшифровки (а иногда и шифрования) сообщений.

Математическая формула расшифровки CBC:

${\displaystyle P_{i}=D_{K}(C_{i})\oplus C_{i-1},}$

${\displaystyle C_{0}=IV.}$

Как показано выше, расшифровка CBC выполняет XOR каждого блока открытого текста с предыдущим блоком. В результате однобайтовая модификация в блоке приведет к соответствующему изменению одного байта в . ${\displaystyle C_{1}}$ ${\displaystyle P_{2}}$

Предположим, злоумышленник имеет два блока зашифрованного текста и хочет расшифровать второй блок, чтобы получить открытый текст . Злоумышленник меняет последний байт (создает ) и отправляет на сервер. Затем сервер сообщает, правильно ли заполнение последнего расшифрованного блока ( ) (действительное заполнение PKCS#7). Если заполнение правильное, злоумышленник теперь знает, что последний байт равен , последние два байта — 0x02, последние три байта — 0x03, … или последние восемь байтов — 0x08. Злоумышленник может изменить предпоследний байт (перевернуть любой бит), чтобы гарантировать, что последний байт равен 0x01. (В качестве альтернативы злоумышленник может перевернуть более ранние байты и выполнить двоичный поиск позиции для идентификации заполнения. Например, если изменение третьего с конца байта правильно, но изменение предпоследнего байта неверно, тогда известны два последних байта. быть 0x02, что позволяет расшифровать их оба.) Следовательно, последний байт равен . Если заполнение неверно, злоумышленник может изменить последний байт на следующее возможное значение. В лучшем случае злоумышленнику потребуется сделать 256 попыток найти последний байт , 255 попыток для каждого возможного байта (256 возможных, минус одна по принципу «котла» ), плюс одна дополнительная попытка устранить неоднозначное дополнение. ^[7] ${\displaystyle C_{1},C_{2}}$ ${\displaystyle P_{2}}$ ${\displaystyle C_{1}}$ ${\displaystyle C_{1}'}$ ${\displaystyle (IV,C_{1}',C_{2})}$ ${\displaystyle P_{2}'}$ ${\displaystyle D_{K}(C_{2})\oplus C_{1}'}$ ${\displaystyle \mathrm {0x01} }$ ${\displaystyle D_{K}(C_{2})}$ ${\displaystyle C_{1}'\oplus \mathrm {0x01} }$ ${\displaystyle C_{1}'}$ ${\displaystyle P_{2}}$

Определив последний байт , злоумышленник может использовать ту же технику для получения предпоследнего байта . Злоумышленник устанавливает последний байт в значение . Затем злоумышленник использует тот же подход, описанный выше, на этот раз изменяя предпоследний байт до тех пор, пока заполнение не станет правильным (0x02, 0x02). ${\displaystyle P_{2}}$ ${\displaystyle P_{2}}$ ${\displaystyle P_{2}}$ ${\displaystyle \mathrm {0x02} }$ ${\displaystyle C_{1}}$ ${\displaystyle D_{K}(C_{2})\oplus \mathrm {0x02} }$

Если блок состоит из 128 бит ( например, AES ), что составляет 16 байт, злоумышленник получит открытый текст не более чем за 256⋅16 = 4096 попыток. Это значительно быстрее, чем попытки подбора 128-битного ключа. ${\displaystyle P_{2}}$ ${\displaystyle 2^{128}}$

Шифрование сообщений с помощью атаки оракула Padding (CBC-R)

CBC-R ^[8] превращает оракул дешифрования в оракул шифрования и в первую очередь демонстрируется против оракулов заполнения.

Используя атаку оракула заполнения, CBC-R может создать вектор инициализации и блок зашифрованного текста для любого открытого текста:

• расшифровать любой зашифрованный текст P _i = PODecrypt( C _i ) XOR C _i-1 ,
• свободно выбрать предыдущий шифрблок C _x-1 ,
• создать действительную пару зашифрованный/открытый текст C _x-1 = P _x XOR PODecrypt( C _i ) .

Чтобы сгенерировать зашифрованный текст длиной N блоков, злоумышленник должен выполнить N атак оракула заполнения. Эти атаки объединены в цепочку, так что правильный открытый текст создается в обратном порядке, от конца сообщения ( _CN ) до начала сообщения ( C ₀ , IV). На каждом этапе используется атака оракула заполнения для построения IV к предыдущему выбранному зашифрованному тексту.

Атака CBC-R не будет работать против схемы шифрования, которая аутентифицирует зашифрованный текст (с использованием кода аутентификации сообщения или аналогичного) перед расшифровкой.

Атаки с использованием оракулов заполнения

Оригинальная атака на CBC была опубликована в 2002 году Сержем Водене . ^[3] Позднее были реализованы конкретные примеры атаки против SSL ^[9] и IPSec. ^{[10] [11]} Он также применялся к нескольким веб-фреймворкам , включая JavaServer Faces , Ruby on Rails ^[12] и ASP.NET ^{[13] [14] [15]} , а также к другому программному обеспечению, такому как игровой клиент Steam . . ^[16] В 2012 году было показано, что он эффективен против криптографических токенов PKCS 11 . ^[1]

Хотя эти более ранние атаки были исправлены большинством разработчиков TLS после его публичного объявления, новый вариант, атака Lucky Thirteen , опубликованная в 2013 году, использовала побочный канал синхронизации для повторного открытия уязвимости даже в ранее исправленных реализациях. По состоянию на начало 2014 года атака больше не считается угрозой в реальной эксплуатации, хотя теоретически она все еще работоспособна (см. Отношение сигнал/шум ) против определенного класса машин. По состоянию на 2015 год ^{[обновлять]}наиболее активной областью разработки атак на криптографические протоколы, используемые для защиты интернет-трафика, являются атаки с понижением версии , такие как атаки Logjam ^[17] и Export RSA/FREAK ^[18] , которые обманом заставляют клиентов использовать менее безопасные криптографические операции. предусмотрено для совместимости с устаревшими клиентами, когда доступны более безопасные. Атака под названием POODLE ^[19] (конец 2014 г.) сочетает в себе атаку понижения версии (до SSL 3.0) с атакой оракула с заполнением старого небезопасного протокола для компрометации передаваемых данных. В мае 2016 года в CVE - 2016-2107 было обнаружено , что исправление Lucky Thirteen в OpenSSL представило еще один оракул заполнения на основе времени. ^{[20] [21]}

Рекомендации

1. Ромен Барду; Риккардо Фокарди; Юсуке Кавамото; Лоренцо Симионато; Грэм Стил; Джо-Кай Цай (2012). Эффективные атаки Oracle с заполнением на криптографическое оборудование. Рр-7944 (отчет). ИНРИА . п. 19.
2. Блэк, Джон; Уртубия, Гектор (2002). Атаки по побочным каналам на симметричные схемы шифрования: аргументы в пользу шифрования с аутентификацией. Безопасность USENET '02.
3. Серж Водене (2002). Недостатки безопасности, вызванные приложениями CBC, заполняющими SSL, IPSEC, WTLS... (PDF) . EUROCRYPT 2002. Аналогичная модель атаки использовалась Блейхенбахером против PKCS#1 v1.5 [5] и Мангером против PKCS#1 v2.0 [13]. В этой статье показано, что подобные атаки возможны в мире симметричных ключей.
4. Салливан, Ник (12 февраля 2016 г.). «Заполнение оракулов и упадок наборов шифров в режиме CBC». Блог Cloudflare .
5. Ханно Бёк; Юрай Соморовский; Крейг Янг. «Атака роботов: возвращение угрозы оракула Бляйхенбахера» . Проверено 27 февраля 2018 г.
6. Мангер, Джеймс (2001). «Атака выбранного зашифрованного текста на оптимальное асимметричное зашифрование RSA (OAEP), стандартизированное в PKCS # 1 v2.0» (PDF) . Исследовательские лаборатории Телстра.
7. Детерминирована ли атака оракула заполнения?
8. Джулиано Риццо; Тай Дуонг (25 мая 2010 г.). Практическое дополнение атак Oracle (PDF) . УСЕНИКС ВУТ 2010.
9. Брайс Канвел; Ален Хильтген; Серж Водене; Мартин Вуаньу (2003), Перехват пароля в канале SSL/TLS (PDF).
10. Жан Поль Дегабриэль; Кеннет Г. Патерсон (2007 г.), Attacking the IPsec Standards in Encryption Configurations (PDF) , заархивировано из оригинала 19 декабря 2018 г. , получено 25 сентября 2018 г..
11. Жан Поль Дегабриэль; Кеннет Г. Патерсон (2010), О (не)безопасности IPsec в конфигурациях с последующим шифрованием MAC , CiteSeerX 10.1.1.185.1534 .
12. Джулиано Риццо; Тай Дуонг (25 мая 2010 г.). Практическое дополнение атак Oracle (PDF) . УСЕНИКС ВУТ 2010.
13. Тай Дуонг; Джулиано Риццо (2011). Криптография в Интернете: пример недостатков криптографического проектирования в ASP.NET (PDF) . Симпозиум IEEE по безопасности и конфиденциальности, 2011 г.
14. Деннис Фишер (13 сентября 2010 г.). «Криптоатака Padding Oracle затронула миллионы приложений ASP.NET». Пост с угрозами . Архивировано из оригинала 13 октября 2010 года.
15. Влад Азархин (19 сентября 2010 г.). «Объяснение уязвимости ASP.NET «Padding Oracle»» . Архивировано из оригинала 23 октября 2010 года . Проверено 11 октября 2010 г.
16. «Взлом криптографии клиента Steam». База данных Steam . Проверено 1 мая 2016 г.
17. Мэтью Грин; Надя Хенингер ; Пол Циммерман; и другие. (2015), Несовершенная прямая секретность: как Диффи-Хеллман терпит неудачу на практике (PDF). Для получения дополнительной информации см. https://www.weakdh.org. Архивировано 22 декабря 2019 г. на Wayback Machine .
18. Мэтью Грин (3 марта 2015 г.). «Атака недели: FREAK (или «факторинг АНБ ради развлечения и прибыли»)».; дополнительную информацию см. на https://www.freakattack.com. Архивировано 5 марта 2015 г. на Wayback Machine .
19. Мэтью Грин (14 октября 2014 г.). «Атака недели: ПУДЛЬ».; дополнительную информацию см. на https://www.poodle.io.
20. Рекомендации по безопасности OpenSSL [3 мая 2016 г.], 3 мая 2016 г.
21. Еще один оракул заполнения в OpenSSL CBC Ciphersuites, Cloudflare, 4 мая 2016 г.